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:00:24 GMT
On Mon, Apr 19, 2010 at 8:15 AM, Clinton Begin <clinton.begin@gmail.com>wrote:

> Thanks Adinath.
>
> This will all help.  Let's figure this out together.
>
> The odd thing for me is this.  A typical transaction lifecycle (be it
> global or otherwise would be:
>
> *  Open Connection
> *  Do Work
> *  Commit or Rollback
> *  Close Connection (even if this implies a return to the connection pool)
>
> The problem with calling close on a connection that's globally managed is
> that it changes the lifecycle to:
>
> *  Open Connection
> *  Do Work
> *  >> Close Connection (even if this implies a return to the connection
> pool)
> *  Commit or Rollback
>
> Now I suppose a smart resource manager controlling the transaction would
> know better than to actually return the connection to the pool until the
> worker thread is finished and the transaction is either committed or rolled
> back, but I'm not entirely confident that all app servers are that smart.


This was my exact dilemma, then I saw an article (which I cannot find now)
that suggested in a managed environment connection.close() marks the
connection for closing but does not actually return the connection to the
pool until the transaction completes, at which point commit() or rollback()
is called on the connection and the connection returned to the pool. This
made perfect sense.

I wrote a set of test cases that opened 2 JDBC connections from the managed
datasource in a session bean and performed a row insert on each connection
to a test table (same table for both inserts). The observation were
consistent with the claim in the article. I observed the following (in the
context of GlassFish v3):

- the container commits the transaction (on both connections) on completion
of the session bean (i.e. no connection.commit() needed)
- committing the transaction on a connection in the code is "bad" (this was
what I expected), since it overrides the EJB transaction
- if setRollbackOnly() is called it rolls back updates made using both
connections
- my attempts to look inside the wrapped connection objects returned show no
evidence that I am getting the same underlying connection handle


> As you noted, glassfish doesn't even warn you when you call commit in a
> managed transaction (most resource managers would throw an exception if
> commit or rollback were called).  I wouldn't be surprised if this is the
> reason you're getting intermittent IllegalStateExceptions.
>

Yes the lack of an exception from GlassFish is a bummer, I am going to take
a closer look at the GlassFish connection pool settings to see if they have
a bearing on this behavior.

I'm going to do a little more reading tonight on JEE 6 standard behavior to
> see if there's one approach we can trust.
>
> The most empirical evidence of the proper behavior would be iBATIS 2, which
> calls close.  But I normally don't remove code without reason (although it
> has happened ;-).
>
> I'll check into this tonight or tomorrow at the latest.
>

Thanks, it seems like I am able get everything working nicely with reliable
transactions except in debug mode (incidentally I use IntelliJ IDEA Ultimate
95.54 EAP), but that is still unnerving. Will continue to look at this today
and update this thread if needed. Appreciate the excellent feedback.

Best,
Adi

-- 
Acciente, LLC
Systems Architecture and Software Design

www.acciente.com
www.inductionframework.org

Mime
View raw message