Nested transactions: settings won't be resetted after inner Trx is done

[nPraml]

Hello @rbygrave,

in our application we have a constellation that we use nested transactions (as in the testcase).
We switch on batchMode in the inner transaction, but unfortunately this also remains switched on for the outer transaction.
mariaDb cannot handle some prepared queries in the outer transaction and throws an exception in our use case.

We assumed that the settings in the nested transaction have no effect on the outer one. Do we assume this correctly?

Cheers
Noemi

[rbygrave]

Firstly some background for folks reading this.

The code in question is like:

    try (Transaction txn1 = DB.beginTransaction(TxScope.requiresNew())) {

      try (Transaction txn2 = DB.beginTransaction()) {
        txn2.setBatchMode(true);
        txn2.commit();
      }
      // resume txn1
      assertThat(txn1.isBatchMode()).isFalse();
    }

Types of Nested transactions

There are 2 types of nested transactios:

• (A) "Savepoints" / Actual real nested transactions
• (B) Nested in a try block (or nested @Transactional methods) ... where there is actually only 1 real database transaction, internally there is a ScopedTransaction which has a stack of ScopeTrans - the nesting here is underlying doing pushing/popping ScopeTrans (but only 1 real underlying database jdbc transaction here).

This question is about (B) Nested in a try blocks case.

This question could be stated approximately as ... when we pop a ScopeTrans should that restore the batchMode (and other similar batch attributes).

The attributes in question are: batchMode, batchOnCascade, batchSize, batchGetGeneratedKeys, flushOnQuery;

---

The reason why this test fails is because ScopeTrans only conditionally stores these attributes (and they are only restored if they were stored).

Q: Why does ScopeTrans not instead just ALWAYS store those current settings and ALWAYS just restore them?
A: I think it should. I think we should simplify this and just always store and restore these attributes. More specifically it would not be expensive to do that, and I see no expensive side effects of doing that.

With that simplification to just always store and restore those attributes in ScopeTrans, this test passes and all tests pass.