FIX: nested NOT_SUPPORTED transaction with an inner REQUIRES transaction

[rPraml]

Hello Rob, we discovered a strange behaviour, when using NOT_SUPPORTED transaction.

We have some import code in our application Our use case is as follow:

try (Transaction txn1 = DB.beginTransaction()) {
      ImportStatus status = DB.find(ImportStatus.class).forUpdate()...findOne(); // find status entity and place lock

      try (Transaction txn2 = DB.beginTransaction(TxScope.notSupported())) {
        // pause current transaction and run import without an active txn
        runImport();
        txn2.commit(); // not really neccessary, it's the NO_TRANSACTION
        status.setSuccess(true);
      } catch (Throwable t) {
        status.setSuccess(false);
      }
      DB.save(status)
}

This works fine, as long the "runImport" will not open new transactions. In this case, the next DB.beginTransaction() will not detect the open stack of txn1 and txn2 and will effectively overwrite the existing txnContainer.

[rPraml]

not longer in use

[rPraml]

is it possible (or allowed) that we will get an instance not implementing ScopedTransaction here?

[rPraml]

if a DB.save(entityWithPersistAction) creates an implicit transaction, we will fail here, if a callback or @PrePersist action tries to create a nested transaction, because implicit transactions are not nestable

[rPraml]

Hmm. There are still some issues, when ebean tries to open some implicit transactions.
See last commit.

I've tried to start fixing it here: 38b5ac2 but I think this will go into the wrong direction.

So the question is: Means "NOT_SUPPORTED" really: Pause current transaction and behave like never a transaction was opened

Note: As workaround we currently experiment with:

try (Transaction txn = DB.beginTransaction()) {
  // find status
  Thread t = new Thread(()-> { /* runs without txn */});
  t.start();
  t.join();
  // update status
}