Validation of existing transactions with transaction synchronization turned off not working (?) [SPR-15016]

[spring-projects-issues]

Vojtech Toman opened SPR-15016 and commented

In out project, we have our own transaction manager implementation. In the test suite, we have a test that checks the various cases in transaction propagation, including the following (requesting a RW transaction while the current transaction is RO):

class A {
  @Autowired
  private B b;

  @Transactional(readOnly = true)
  public void readOnly() {
    b.readWrite();
  }
}

class B {
  @Transactional(propagation = Propagation.REQUIRED, readOnly = false)
  public void readWrite() {
    ...
  }
}

As expected, the call to b.readWrite() fails with an IllegalTransactionStateException. However, when I disable transaction synchronization in our transaction manager, I don't get an exception any more. In the code of AbstractPlatformTransactionManager.handleExistingtransaction(), I see that the check for this case uses TransactionSynchronizationManager.isCurrentTransactionReadOnly() which, obviously, returns false if transaction synchronization is turned off. I believe this is a bug. (It's possible that this follows from the semantics of transaction synchronization in which case I would be grateful if somebody could explain me the reasoning behind this).

---

Affects: 4.3.4

Issue Links:

• Log warning for Isolation.READ_UNCOMMITTED with Propagation.NOT_SUPPORTED [SPR-12600] #17201 Log warning for Isolation.READ_UNCOMMITTED with Propagation.NOT_SUPPORTED

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is by design: Without synchronization active, outer vs inner transaction scopes only communicate via the resources involved, not seeing each other's transaction definition metadata. Validating Spring transaction definitions across demarcation levels is indeed a feature that only comes in through the transaction synchronization arrangement. Also, we're only really using it for validation purposes around transaction hints here: The transaction read-only flag was never meant to be a hard constraint but rather just a soft hint for runtime optimizations in a read-only scenario.