ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Assmann (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Created: (IBATIS-408) Bug Using Statement Caching With iBATIS 2.3.0 And Spring Framework?
Date Tue, 20 Mar 2007 08:40:32 GMT
Bug Using Statement Caching With iBATIS 2.3.0 And Spring Framework?

                 Key: IBATIS-408
                 URL: https://issues.apache.org/jira/browse/IBATIS-408
             Project: iBatis for Java
          Issue Type: Bug
          Components: SQL Maps
    Affects Versions: 2.3.0
            Reporter: Ralf Assmann

This is the description how to get the problem. I think it is a bug ...

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

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

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. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message