Ibatis + apache BasicDataSource + Spring DAO + autocommit

[javaguy44]

Hi,

I saw this excellent post by Clinton http://www.nabble.com/Proper-transaction-code-pattern-(was:-Autocommit-not-properly-handled-in-Ibatis)-td8505967.html#a8505967

and after a few hours of playing around + googling, I was wondering if someone can clear up the case of ibatis + BasicDataSource + Spring DAO + DataSourceTransactionManager + autocommit.  I think this would benefit others too as this is a common setup.

I've managed to turn off autocommit by changing the BasicDataSource.defaultAutoCommit property

However I was under the assumption that leaving autocommit off in this scenario, I would still be able to commit using sqlMapClient.begin, commit, endTransaction but this is not the case.

Would appreciate if someone can expand on the following:
 - is the appropriate place to turn auto commit off in BasicDataSource in this scenario?
 - if auto commit is off in this manner, should sqlMapClient.start, commit, endTransaction work?
 - if auto commit is off and using Ibator to generated SpringDAO's, my records no longer persist to the DB.  If this scenario is supposed to use sqlMapClient.start, commit, endTransaction, can Ibator generate?

Thanks

[Rick.Wellman]

Welcome to my world.  I recently trudged down this road myself and found
the help/warnings in this area lacking (readers: PLEASE feel free to
point out web documentation to refute me on that statement!).

As there are six items in your "stack" (ibatis + BasicDataSource +
Spring DAO + DataSourceTransactionManager + autocommit) I will try to
keep my response focused on that stack.  (However, I do not use Spring
DAO but I do use Spring and create my SqlMapClient with Spring's
SqlMapClientFactoryBean so I think my response will be applicable.
After my response, you might post your Spring configuration so we can
see who all the "players" are in your configuration.)

Your questions, my responses:
However I was under the assumption that leaving autocommit off in this
scenario, I would still be able to commit using sqlMapClient.begin,
commit, endTransaction but this is not the case.
>>>[rw] Yeah, I ran into this too.  I am pretty sure it is because of
DataSourceTransactionManager.

- is the appropriate place to turn auto commit off in BasicDataSource in
this scenario?
>>>[rw] Sorry for this half-ass answer but I think it is already off or
turned off by the configuration you specify. I "blindly" used
SqlMapClientFactoryBean which was sufficient before I started tackling
transaction handling.  However, when I ran into the same things you are
running into, I found the operation and documentation around this
factory quite confusing.  (again, my experience... it would be nice if
there were three or four documented most-used scenarios for using this
Spring class.)

 - if auto commit is off in this manner, should sqlMapClient.start,
commit, endTransaction work?
>>>[rw] I will have to defer to more of the experts on this forum.  I
could not find a way to make it work.  Again, I think it becomes
disabled/overridden by the use of an "external" transaction manager.

 - if auto commit is off and using Ibator to generated SpringDAO's, my
records no longer persist to the DB.  If this scenario is supposed to
use sqlMapClient.start, commit, endTransaction, can Ibator generate?
>>>[rw] I cannot address Ibator but I can offer this:  What I ended up
doing (which maybe the experts can lend an opinion on), is using the
instance of DataSourceTransactionManager and its methods.  The following
code snippets are from our code which is probably not a great
implementation but it's a combination of our legacy architecture and my
understanding of how to make transactions work (you can probably ignore
the Boolean 'txEnabled'):

    @Override
        protected void txBegin(HttpServletRequest request) {
            if (txEnabled) {
            final DefaultTransactionDefinition td = new
DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_REQUIRED)
;
 
td.setIsolationLevel(TransactionDefinition.ISOLATION_SERIALIZABLE);
            td.setTimeout(60);        
            final DataSourceTransactionManager tm =
(DataSourceTransactionManager)request.getAttribute("txResource"); // tm
:= transaction manager        
                final TransactionStatus status = tm.getTransaction(td);
               
                request.setAttribute("txStatus", status); // txStatus is
only recognized/used by this application
            }    
        }
       
    @Override
        protected void txCommit(HttpServletRequest request) {
        if (txEnabled) {
            final DataSourceTransactionManager tm =
(DataSourceTransactionManager)request.getAttribute("txResource"); // tm
:= transaction manager
            final TransactionStatus status = (TransactionStatus)
request.getAttribute("txStatus");
            tm.commit(status);
        }      
        }
       
    @Override
        protected void txRollback(HttpServletRequest request) {
        if (txEnabled) {
            final DataSourceTransactionManager tm =
(DataSourceTransactionManager)request.getAttribute("txResource"); // tm
:= transaction manager
            final TransactionStatus status = (TransactionStatus)
request.getAttribute("txStatus");
            tm.rollback(status);
        }      
        }
       
    @Override
    protected void txEnd(HttpServletRequest request) {
    }


-----Original Message-----
From: javaguy44 [mailto:javaguy44@...]
Sent: Thursday, October 22, 2009 5:36 PM
To: user-java@...
Subject: Ibatis + apache BasicDataSource + Spring DAO + autocommit


Hi,

I saw this excellent post by Clinton
http://www.nabble.com/Proper-transaction-code-pattern-(was:-Autocommit-n
ot-properly-handled-in-Ibatis)-td8505967.html#a8505967

and after a few hours of playing around + googling, I was wondering if
someone can clear up the case of ibatis + BasicDataSource + Spring DAO +
DataSourceTransactionManager + autocommit.  I think this would benefit
others too as this is a common setup.

I've managed to turn off autocommit by changing the
BasicDataSource.defaultAutoCommit property

However I was under the assumption that leaving autocommit off in this
scenario, I would still be able to commit using sqlMapClient.begin,
commit,
endTransaction but this is not the case.

Would appreciate if someone can expand on the following:
 - is the appropriate place to turn auto commit off in BasicDataSource
in
this scenario?
 - if auto commit is off in this manner, should sqlMapClient.start,
commit,
endTransaction work?
 - if auto commit is off and using Ibator to generated SpringDAO's, my
records no longer persist to the DB.  If this scenario is supposed to
use
sqlMapClient.start, commit, endTransaction, can Ibator generate?

Thanks
--
View this message in context:
http://www.nabble.com/Ibatis-%2B-apache-BasicDataSource-%2B-Spring-DAO-%
2B-autocommit-tp26018335p26018335.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...