ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adinath <adin...@acciente.com>
Subject Re: Transaction management in iBATIS 3 inside an EJB (3.1) container
Date Mon, 19 Apr 2010 18:07:44 GMT
On Mon, Apr 19, 2010 at 10:33 AM, Guy Rouillier <guyr-ml1@burntmail.com>wrote:

> I haven't been following this thread closely, but with JBoss at least, you
> have the option of configuring datasources as no-transaction:
> no-tx-datasource.  With this type of datasource, you are free to call commit
> and rollback yourself.  With container-managed transactions, you should not
> be calling commit or rollback.  I've erroneously done so, and JBoss
> generates an error saying that these methods are illegal on a container
> managed transaction.
>

I agree, commit()/rollback() should not be called on the container managed
connections.


>
> Regarding your thoughts about a smart resource manager, that is indeed what
> happens.  Remember that datasource may be retrieved and closed any number of
> times during the processing of a single EJB method.  During the execution of
> single EJB method, the container is required by the spec to return the same
> physical connection each time getConnection() is invoked, so that all
> database activity within that method (which can of course call other
> methods) is guaranteed to be within the same transaction.
>

What about a method in bean A that call a method a different bean say B,
does the spec require that B gets the same underlying connection? In
GlassFish I suspect I am getting completely independent connections, I need
to verify this.


> Only when the EJB method completes does the container do the commit or
> rollback and then returns the connection to the pool as available for use.
>
> Since iBATIS can't possible determine that it is being used in a
> container-managed transaction, if you want to support that, I would think
> the only possibility is to provide an optional parameter in the data source
> configuration to indicate that.  In such cases, iBATIS should probably no-op
> commit and rollback.


IBATIS does not need a config parameter, you can do this by implementing a
simple transaction factory.

Best,
Adi

-- 
Acciente, LLC
Systems Architecture and Software Design

www.acciente.com
www.inductionframework.org

Mime
View raw message