ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baldur Norddahl <bbn-iba...@inaphone.com>
Subject Re: session leak in ibatis 2.0.8
Date Wed, 29 Dec 2004 08:29:38 GMT

Ok I tried to write a test script and couldn't reproduce it either. But 
at last I managed to find the real bug (which can be reproduced).

My projects where converted from ibatis 1 and we had some code blocks 
like this one:

SqlMapClient db = null;
  db = getSqlMapClient();
} finally
  if (db!=null) db.endTransaction();

The problem is the null check in the last statement. iBatis 1 required 
this, but iBatis2 does not release the resource unless you run 
endTransaction() even if you did a commitTransaction().

So in summary, if you run commitTransaction() without endTransaction() 
you get a session leak.

Another question: iBatis2 leaves all my connections in state "idle in 
transaction". With iBatis1 (and other frameworks) the connections are 
just in "idle" state. This is a little annoying because "idle in 
transaction" is a warning signal that someone forgot a commit somewhere. 
Will it be possible to add a setting to get the old behavior back?


Clinton Begin wrote:

>I just ran through the unit tests which use an update, just as you've
>described above.  I cannot recreate the problem.  I even stepped
>through with a debugger and watched the resource close.  The end state
>after my update was a session pool size of 0.  endTransaction() is
>automatically called in SqlMapExecutorDelegate (see
>That logic has not changed since the initial 2.0 release, which makes
>me wonder how such a serious problem wouldn't have been discovered by
>thousands of users in nearly 9 months.
>I'm not sure what is different about your environment.  Could you put
>together a simple unit test to demonstrate the problem?
>On Tue, 28 Dec 2004 17:18:25 +0100, Baldur Norddahl
><bbn-ibatis@inaphone.com> wrote:
>> Clinton Begin wrote: 
>> endTransaction after every query. YES! It is by design that you have to
>>GUARANTEE to call endTransaction() if startTransaction() is called. So make
>>sure to call it in a finally block. Here's the example from the docs
>> startTransaction() was never called. You have to call endTransaction()
>>anyway because ibatis forgets to close the session and return the db
>>connection to the pool.
>> try { sqlMap.startTransaction (); // .... do work sqlMap.commitTransaction
>>(); } finally { sqlMap.endTransaction (); } Or, if you just call one of the
>>work methods (queryForX, insert, update, delete etc.), then iBATIS does this
>>for you (i.e. you don't call startTransaction()). 
>> No, that is what I am trying to say. iBatis does NOT call endTransaction()
>>when you work without startTransaction(). It only commits your work, but
>>forgets to release the resource.
>> Baldur

View raw message