ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Transaction management in iBATIS 3 inside an EJB (3.1) container
Date Wed, 21 Apr 2010 02:48:34 GMT
Okay, I've looked around.  It is really hard to find the way it's "supposed"
to work, but I don't think it matters.  There's more than enough empirical
evidence (both in iBATIS 2 and Adinath's custom implementation).  So I've
added the close to the ManagedTransaction.  It will log but otherwise ignore
exceptions thrown by close(), to deal with unexpected states (and
re-throwing an exception from close could hide a more important root cause

The funny thing is that I even had a unit test asserting this behavior, so I
must have done it at some point for a reason. I just hope it wasn't a very
good reason.  ;-)   It's also funny that it wasn't found in 10 betas...
which either implies that not many people use  managed transactions, or that
some app servers behave as I thought they would.

I'm going to recommend a re-build before we take iBATIS 3 to GA, so the
iBATIS release we'll vote on will probably be 3.0.1.


On Mon, Apr 19, 2010 at 7:54 PM, Guy Rouillier <guyr-ml1@burntmail.com>wrote:

> 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