rollback on BatchExecutor executes batched statements

[GoogleCodeExporter]

What version of the MyBatis are you using?
3.0.3

Please describe the problem.  Unit tests are best!
BatchExecutor actually executes all the SQL statements that have been batched 
up in doFlushStatements(). This method is called by 
BaseExecutor.flushStatements, which is in turn called by commit and rollback. 
Obviously, this has to happen for commit, but for rollback, this is redundant 
work - the statements are executed just to be subsequently rolledback by the DB.

What is the expected output? What do you see instead?
There needs to be some kind of separation between clearing an Executors 
internal state and doing other work. There is no need to do the work on 
rollback (or, indirectly, close).

Please provide any additional information below.

Original issue reported on code.google.com by hpresnall@gmail.com on 28 Nov 2010 at 4:24

[GoogleCodeExporter]

Can be easily fixed with a flag to skip the execution of statements in case of 
rollback.
Patch attached.

Original comment by eduardo.macarron on 3 Jan 2011 at 9:39

• Added labels: Component-SqlMaps

[GoogleCodeExporter]

fixed in r3553

Original comment by eduardo.macarron on 3 Jan 2011 at 9:08

• Changed state: Fixed
• Added labels: Target-Release3.0.5

[GoogleCodeExporter]

I try Release 3.0.5 , but I think it is not fixed.

BaseExecutor's rollback call flushStatements with false.
Is it to be flushStatements(required) ?

Original comment by ShinjiSa...@gmail.com on 2 Jun 2011 at 7:52

[GoogleCodeExporter]

Thanks for the notice. It seems wrong it should be flushStatements(true) on 
rollback. 

Original comment by eduardo.macarron on 2 Jun 2011 at 8:12

• Changed state: Accepted
• Added labels: Target-Release3.0.6
• Removed labels: Target-Release3.0.5

[GoogleCodeExporter]

fixed in r3781 

Original comment by eduardo.macarron on 3 Jun 2011 at 7:09

• Changed state: Fixed

[GoogleCodeExporter]

Issue 349 has been merged into this issue.

Original comment by eduardo.macarron on 24 Jun 2011 at 3:27

[GoogleCodeExporter]

This doesn't look to be fixed yet.

try {

sqlSession.delete("com.UserMapper.deleteFromStagingTable");

                LOG.debug("Deleted Records ");

                for (UserVO vo : UserList) {

                    sqlSession.insert("com.UserMapper.insertDataIntoStagingTable", vo);
                }
                LOG.debug("Inserted Records ");
                throw new Exception("Error Occured while throwing ");
            }catch(Exception ex){
                LOG.debug("Error occured in UserDAOImpl.insertDataIntoStagingTable ",ex);

                throw ex;
            }finally {
            }

Even after throwing the exception the rollback doesn't happen

Spring configs are as follows

     <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
         <property name="dataSource" ref="SblMisDataSource"/>
         <property name="rollbackOnCommitFailure" value="false" />
     </bean>

    <bean id="SblMisSqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="SblMisDataSource" />
    <property name="configLocation" value="classpath:com/config/mybatis-config.xml" />
    </bean>

    <bean id="sqlSession" class="org.mybatis.spring.SqlSessionTemplate">
        <constructor-arg index="0" ref="SblMisSqlSessionFactory" />
        <constructor-arg index="1" value="BATCH" />
    </bean>

Original comment by itnav...@gmail.com on 4 Aug 2011 at 1:23

[GoogleCodeExporter]

Original comment by eduardo.macarron on 3 Mar 2012 at 9:11

• Added labels: Version-Release3.x