Add warning and/or exception facility to propagating transactions that try to change the isolation level [SPR-4192]

[spring-projects-issues]

Alef Arendsen opened SPR-4192 and commented

Consider the following

@Transactional(propagation=REQUIRED, isolation=Isolation.REPEATABLE_READ) public void doIt() {
otherService.doSomethingElse();
}

@Transactional(propagation=REQUIRED, isolation=Isolation.READ_COMMITTED) public void doSomethingElse() {}

This situation would essentially ignore the second isolation level. From the point of view of the second method, you're not getting the expected behavior.

It would be good if we had a facility that would allow us to configure if something like this comes up Spring would

1. throw an Exception or
2. issue a warning in the log

This would greatly help to prevent potential logical programming errors...

---

Affects: 2.5 final

Issue Links:

• Doc: @Transactional.isolation does not guarantee the specified isolation level [SPR-16463] #21008 Doc: @Transactional.isolation does not guarantee the specified isolation level

[spring-projects-issues]

Juergen Hoeller commented

This particular scenario makes me wonder whether we should only issue a warning (or raise an exception) when an inner transaction requires a higher isolation level? Since in your scenario, doSomethingElse will semantically be happy with REPEATABLE_READ as well, since all it relies on is READ_COMMITTED... Whereas if it specified SERIALIZABLE, it would obviously have stronger isolation requirements than what the outer transaction provides.

Juergen

[spring-projects-issues]

Alef Arendsen commented

At first sight I would agree. However, if for example a certain isolation level would require locks (DB/2?), from the inner transaction's perspective (which want might use READ_UNCOMMITTED on purpose, simply to avoid locking for example), you might still might not want this to happen (ie run in a less relaxed isolation level).

In other words: the inner transaction might do it on purpose but does not get the level it wants...

Rare use case I would say, but still...

[spring-projects-issues]

Juergen Hoeller commented

I've added a "validateExistingTransaction" property to AbstractPlatformTransactionManager, for corresponding isolation level and read-only checks. This will eagerly throw an IllegalTransactionStateException when encountering an existing transaction with incompatible settings. The default remains "false", for backwards compatibility as well as for leniently trying a best effort execution in such a scenario.

Juergen