Incorrectly set actualTransaction in AbstractPlatformTransactionManager.resume? [SPR-1469]

[spring-projects-issues]

Steven Bazyl opened SPR-1469 and commented

It looks like there is a bug in how the actualTransaction flag is set when resuming. If a transaction with PROPAGATION_SUPPORTS, the flag is correctly set to false. But if the tx is suspended by calling code with REQUIRES_NEW, the reume method will always restore the flag with the value 'true' rather than check to see whether or not the resumed transaction was real or not. Subsequent checks to see if the TX is an actual transaction or not will fail.

I'll attach test code shortly...

---

Affects: 1.2.5

[spring-projects-issues]

Juergen Hoeller commented

Actually, that situation should never arise: A "non-actual" transaction (as caused by PROPAGATION_SUPPORTS) will never get suspended and thus cannot get resumed either. Suspend/resume behavior only applies to actual transactions, at least for the out-of-the-box AbstractPlatformTransactionManager... Can you give me details on your scenario here?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

If you want actual transaction suspension, I would strongly recommend to use PROPAGATION_REQUIRED for the outer transaction and PROPAGATION_REQUIRES_NEW for the inner transaction. PROPAGATION_SUPPORTS is mainly meant for operations that do not have any further, fine-grained transaction demarcation within.

Concretely, PROPAGATION_SUPPORTS at the outer level does not cause the inner PROPAGATION_REQUIRES_NEW to suspend the transaction. Instead, the inner transaction will simply operate on the resources of the outer transaction scope (which will be turned into transactional state for the inner scope).

Juergen

[spring-projects-issues]

Steven Bazyl commented

We probably can just change to PROPAGATION_REUIRES,readonly for this particular case. However, there is an inconsistancy between the different transaction managers, and the behavior I was looking for is available using DataSourceTransactionManager. In that case, the isExistingTransaction() call only checks to see if a DataSource is bound, but doesn't bother to check if a real transaction exists. Actually, this creates some really bizarre behaviors since the suspend behavior will be different depending on the sequence of calls.

For example:

begin PROPAGATION_SUPPORTS
do something with JDBC - Will use connection #1 with no TX context
begin PROPAGATION_REQUIRED
do something else with JDBC - Will use connection #2 with TX
end
do more with JDBC - Will use connection #1, still without TX context
end

vs.

begin PROPAGATION_SUPPORTS
begin PROPAGATION_REQUIRED
do something else with JDBC - Will use connection #1 with TX
end
do more with JDBC - Will use connection #1, TX already comitted
end

Whether or not a datasource has been used before the inner transaction significantly changes the behavior. This isn't a good thing.

Anyway, I understand your description and think its probably OK, but it probably needs to be more clearly stated in the docs what the behavior is, particularly considering that is not the behavior with the DataSourceTransactionManager.

[spring-projects-issues]

Juergen Hoeller commented

I've already addressed this in 1.2.6: DataSourceTransactionManagers uses a "transactionActive" flag in the ConnectionHolder now to track the actual transactional status of a thread-bound Connection. It will only consider an actual transactional Connection as existing transaction now, which should lead to consistent behavior in all scenarios.

Juergen