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 Wed, 29 Dec 2004 17:50:51 GMT
Hi Baldur,

Glad you found the problem.  

The 'idle in transaction' might be caused by the new 2.0 performance
enhancement that only commits when required (i.e. on an update). 
However, some DBMS require that you commit, even after just a query.

You can set commitRequired="true" on the transaction manager to resolve this.

Clinton


On Wed, 29 Dec 2004 09:29:38 +0100, Baldur Norddahl
<bbn-ibatis@inaphone.com> wrote:
> Hi,
> 
> 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;
> try
> {
>   db = getSqlMapClient();
>   db.startTransaction();
>   db.update("something",null);
>   db.commitTransaction();
>   db=null;
> } 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?
> 
> Baldur
> 
> 
> Clinton Begin wrote: 
> Baldur,

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
autoEndTransaction()).

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?

Clinton


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

 
>

Mime
View raw message