[
https://issues.apache.org/jira/browse/IBATIS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489344
]
Ralf Assmann commented on IBATIS-408:
-------------------------------------
Is there a timing when this issue will be solved / worked on?
> Statement Caching Does Not Work / 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
> Priority: Blocker
>
> Using iBATIS statement caching, it will not work. Every statement, althought
> called several times, will be prepared every time again. This is very bad for
> performance doing thousand of inserts, selects and updates in a transaction
> (in fact, bulk insert etc. will not work because of the application).
> This is the description how to get the problem:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
