title: Does Spring's PlatformTransactionManager require transactions to be committed in a specific order?
body: <p>I am looking to retrofit our existing transaction API to use Spring’s <code>PlatformTransactionManager</code>, such that Spring will manage our transactions. I chained my <code>DataSource</code>s as follows:</p>
  
  <p><code>DataSourceTransactionManager</code> - > <code>LazyConnectionDataSourceProxy</code> - > <code>dbcp.PoolingDataSource</code> - > <code>OracleDataSource</code></p>
  
  <p>In experimenting with the <code>DataSourceTransactionManager</code> , 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 <strong>LIFO</strong> fashion, i.e. you must commit/rollback the most recently created transactions first. </p>
  
  <p>Example:</p>
  
  <pre><code>@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.IllegalStateException: Cannot deactivate transaction synchronization - not active
      }
  }
  </code></pre>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>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.</p>
  
  <p>Thanks!</p>