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: session leak in ibatis 2.0.8
Date Tue, 28 Dec 2004 17:08:25 GMT

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
> (again): 
>  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