ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-408) Statement Caching Does Not Work / Bug Using Statement Caching With iBATIS 2.3.0 And Spring Framework!
Date Tue, 17 Apr 2007 13:21:15 GMT

    [ https://issues.apache.org/jira/browse/IBATIS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489398

Clinton Begin commented on IBATIS-408:

If I'm reading this right, this is the intended behavior.  

The statement cache is session scope.  So yes, when you close your session, the cached statement
goes away.  We do not allow cross-transaction/session cached statements because it causes
problems with more database drivers than not.

Seriously, using batch updates and statement caching I've been able to perform 15000 updates
per second on SQL Server.  If that's not fast enough, I don't think iBATIS is right for this
particular task.


> Statement Caching Does Not Work / Bug Using Statement Caching With iBATIS 2.3.0 And Spring
> -----------------------------------------------------------------------------------------------------
>                 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.

View raw message