ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guy Rouillier <guyr-...@burntmail.com>
Subject Re: Transaction management in iBATIS 3 inside an EJB (3.1) container
Date Tue, 20 Apr 2010 01:54:07 GMT
On 4/19/2010 2:07 PM, Adinath wrote:
>     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.

Should return the same connection.  One EJB is allowed to invoke 
another, and the container is supposed to identify that it is already in 
a transaction and not start a new one.

>     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.

I'm not following you.  iBATIS is told to use a JNDI datasource X.  How 
can it determine if it is running (e.g.) in a JBoss environment with a 
no-tx-datasource, in which case it needs to do commit() and rollback() 
before closing the connection?  Or if it is running in a JBoss 
environment with a local-tx-datasource, in which case it cannot do a 
commit() or rollback() before closing the connection?

Are you suggesting that in the second case, the programmer can supply a 
do-nothing transaction manager?  That approach imposes that requirement 
on everyone who uses iBATIS.  Certainly just supplying a param makes 
life easier for a lot of people.

Guy Rouillier

To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

View raw message