ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralf Assmann <ralf.assm...@innovations.de>
Subject Bug Using Statement Caching With iBATIS 2.3.0 And Spring Framework?
Date Tue, 03 Apr 2007 05:06:50 GMT

Hello everybody,

once again, after getting no answers :-( Does anybody has the same
problem / bug or I am the only one using statement caching?

Since iBATIS 2.3.0, the statement caching is enabled. Unfortunately, I
have a problem which maybe seems to be a bug. At least, I am not able to
use the statement caching althought it is enabled. I am using iBATIS
together with the Spring Framework. In the following steps, I try to
explain you the problem I have.

In my iBATIS configuration, the parameter "statementCachingEnabled" is
set to "true". This works fine, using class SqlMapConfigParser.java,
where the value is read as well as reading the parameter in the class
SessionScope.java.

Now, calling a statement the first time, it will be added to the
"prepareStatements"-HashMap of class SessionScope.java, using method
"putPreparedStatement".

The problem now is, that calling the constructor of
SqlMapSessionImpl.java using the method openSession() of class
SqlMapClientImpl.java, the session-attribute (with is from class
SessionScope.java) is set to "default".  This all happens calling the
execute-method of class SqlMapClientImpl.java (1). Further on, if there
is a lookup in the statement cache using the prepareStatement-method of
class SqlExecutor.java, there are no cached statements available,
because the map in session (of class SessionScope.java) is empty. So,
the current statement will be added to the statement cache-attribute,
working well. Calling the closeStatement-method of class
SqlExecutor.java , the added prepared statement will not be close,
because it is listed in the cache. This also works well.

After the statemet was added to the statement cache and executed, it
will be return to the execute-method of SqlMapClientImpl.java (same
methode as marked with (1) above). In the finally-block, the session (of
class SqlMapSessionImpl.java) will be closed. This includes, that the
session-attribute of this class (attribute of class SessionScope.java)
will also be set to null. Now, the statement cache not longer exists. If
calling the execute-method the next time with the same statement, the
session-attribute (of class SessionScope.java), which will be get from
the popSession-method of class SessionScope.java, using the sessionPool
(of class ThrottledPool.java), there are no cached statements in it.
They have been "deleted" as described before.

So, the problem is not that statements are not added to the statement
cache. The problem is, that they will be "deleted" from the statement
cache to earlier. Every time calling the execute-methode (as marked in
(1)), a statement will be added to the list. But it will be "deleted"
after running the finally-block of this method.

Last but not least: The execute-method I referred to above was called 
using Spring's
getSqlMapClientTemplate-method (extended from SqlMapClientDaoSupport.java)
and using this template's insert-method.

Please, can you have a look for this and tell me, if this really is a
bug (and I am right) or if I am only unable to use the statement cache
as designed?

If the description above is too confusing, let me know :-)

Many thanks for your efforts.

Best regards,


Ralf Assmann

-------------------------------------------------------------------
Ralf Assmann, Dipl.-Ing. (FH)
Innovations Softwaretechnologie GmbH
Ziegelei 7, 88090 Immenstaad, Germany
Tel.: +49 7545 202-324
Tel.: +49 7545 202-300 (Zentrale)
Fax.: +49 7545 202-301
Email: ralf.assmann@innovations.de
Web: http://www.innovations.de
-------------------------------------------------------------------
Geschaeftsfuehrung: Achim Berger, Thomas Cotic, Walter Pitz
Reg.-Gericht Ulm HRB 631622
-------------------------------------------------------------------



Mime
View raw message