Atomikos Forum

Not ending transaction (set implicit transaction off)

MSSQL 2000 + JTDS + Atomikos 3.3.3 + Spring 2.5

When Atomikos commit transaction on MSSQL strange thigs happens.

On transacton start : SET IMPLICIT_TRANSACTIONS ON
(This is OK)

On transaction commit : IF @@TRANCOUNT > 0 COMMIT TRAN
(This seems be ok but NOT)

After this another transaction is imediatelly started!
But we dont want this - we dont start new  transaction!

Right commit command is :
IF @@TRANCOUNT > 0 COMMIT TRAN; SET IMPLICIT_TRANSACTIONS OFF



Reproduce config :

Two com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean

    <bean id="atomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager" init-method="init" destroy-method="close">
        <!--  when close is called, should we force transactions to terminate or not? -->
        <property name="forceShutdown"><value>true</value></property>
    </bean>

    <!-- Also use Atomikos UserTransactionImp, needed to configure Spring  -->
    <bean id="atomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp">
        <property name="transactionTimeout"><value>300</value></property>
    </bean>

    <bean id="dataSource" parent="dataSourceParent" depends-on="jdbc.properties">
        <property name="uniqueResourceName"><value>NONXADBMS-DAISY</value></property>
        <property name="user"><value>${jdbc.username}</value></property>
        <property name="password"><value>${jdbc.password}</value></property>
        <property name="url"><value>${jdbc.url}</value></property>
    </bean>


    <bean id="dataSourceH" parent="dataSourceParent" depends-on="jdbc.properties">
        <property name="uniqueResourceName"><value>NONXADBMS-DAISY-HIST</value></property>
        <property name="user"><value>${jdbc.h.username}</value></property>
        <property name="password"><value>${jdbc.h.password}</value></property>
        <property name="url"><value>${jdbc.h.url}</value></property>
    </bean>
cesnek Send private email
Tuesday, September 23, 2008
 
 
Hi,

Nowhere in the Atomikos code base is code that contains those SQL statements.

I suspect they are fired by the JDBC driver itself and my guess is that those statements have to do with the setAutoCommit() / commit() calls.

I'm sorry but I doubt there is much we can do so you should direct your question to your JDBC driver supplier.
Ludovic Orban Send private email
Wednesday, September 24, 2008
 
 
WRONG !!

When atomikos starting transaction issue command :
wrapped.setAutoCommit ( false );


When ending transaction with commit/rollback you must cleanup connection to origin state - so setAutoCommit(true)


Correct code :

            if ( commit ) {
                Configuration.logInfo ( "ThreadLocalConnection: committing on connection...");
                try {
                    wrapped.commit ();
                }finally {
                    try {
                        wrapped.setAutoCommit(true);
                    }catch (Exception ex){
                        Configuration.logWarning ( "wrapped.setAutoCommit(true) throw exception "+ex.getMessage(), ex);
                    }
                }
            } else {
                Configuration.logInfo ( "ThreadLocalConnection: rolling back on connection...");
                try {
                    wrapped.rollback ();
                }finally {
                    try {
                        wrapped.setAutoCommit(true);
                    }catch (Exception ex){
                        Configuration.logWarning ( "wrapped.setAutoCommit(true) throw exception "+ex.getMessage(), ex);
                    }
                }
            }


Realy good code should check autocommit status at starting transaction and in the end restore origin state. Not just setAutoCommit(true) but setAutoCommit(originAutoCommitState).
cesnek Send private email
Wednesday, September 24, 2008
 
 
Hi,

Thanks! We are always looking for new committers and contributors - if you are interested please contact support@atomikos.com

Cheers
Guy Pardon Send private email
Friday, September 26, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics