Does Spring's PlatformTransactionManager require transactions to be committed in a specific order?

I am looking to retrofit our existing transaction API to use Spring’s PlatformTransactionManager, such that Spring will manage our transactions. I chained my DataSources as follows:

DataSourceTransactionManager - > LazyConnectionDataSourceProxy - > dbcp.PoolingDataSource - > OracleDataSource

In experimenting with the DataSourceTransactionManager , I have found that where PROPAGATION_REQUIRES_NEW is used, it seems that Spring’s transaction management requires that the transactions be committed/rolled back in LIFO fashion, i.e. you must commit/rollback the most recently created transactions first.

Example:

@Test
public void testSpringTxns() {

    // start a new txn
    TransactionStatus txnAStatus = dataSourceTxnManager.getTransaction(propagationRequiresNewDefinition); // specifies PROPAGATION_REQUIRES_NEW
    Connection connectionA = DataSourceUtils.getConnection(dataSourceTxnManager.getDataSource());     

    // start another new txn
    TransactionStatus txnBStatus = dataSourceTxnManager.getTransaction(propagationRequiresNewDefinition);
    Connection connectionB = DataSourceUtils.getConnection(dataSourceTxnManager.getDataSource());

    assertNotSame(connectionA, connectionB);
    try {

        //... do stuff using connectionA
        //... do other stuff using connectionB
    } finally {
        dataSourceTxnManager.commit(txnAStatus);
        dataSourceTxnManager.commit(txnBStatus); // results in java.lang.Illeg开发者_如何学编程alStateException: Cannot deactivate transaction synchronization - not active
    }
}

Sadly, this doesn’t fit at all well with our current transaction API which allows you to create transactions, represented by Java objects, and commit them in any order.

My question: Am I right in thinking that this LIFO behaviour is fundamental to Spring’s transaction management (even for completely separate transactions)? Or is there a way to tweak its behaviour such that the above test will pass?

I know the proper way would be to use annotations, AOP, etc. but at present our code is not Spring-managed, so it is not really an option for us.

Thanks!

yes,I have met the same problems below when using spring: java.lang.IllegalStateException: Cannot deactivate transaction synchronization - not active.

According above,Spring’s transaction management requires that the transactions be committed/rolled back in LIFO fashion(stack behavior).The problem disappear.

thanks.

Yes, I found this same behavior in my own application. Only one transaction is "active" at a time, and when you commit/rollback the current transaction, the next active transaction is the next most recently started transaction (LIFO/stack behavior). I wasn't able to find any way to control this, it seems to be built into the Spring Framework.