Transaction propagation and exception rollback

[scesbron]

Thanx for your explanation Juergen.

It seems clear to me that this behaviour is driven by transaction best practices. As I am not an expert in that domain, I will follow your recommandation.
The only case where the setRollbackOnly(false) seems useful for me is the one mentionned in my previous post. Use of creation method inside a batch. I think I can invoke the DAO directly from the batch instead of invoking a fine grained service. The only drawback is that I may have to duplicate code between my two services.

Thanx again for the clarification

[johnzhang]

A facade bean will be usually enough given the context that it is the crucial operation of a transaction. If it fails, everything fails. But when the facade is just a screw in a machine and not supposed to stop the whole thing running, rollback is not suitable. However, that seems to be the way defined in the EJB 2.1 spec, and the current Spring 1.2.2 is actually complying with that behaviour.

So I am wondering how you are going to change it in 1.3 RC1 (SPR-1029)? Does the EJB spec have any changes at this point?

No matter what, I really appreciate your patience and professional answers!

[Juergen Hoeller]

FYI, I've added a "globalRollbackOnParticipationFailure" flag to AbstractPlatformTransactionManager, with default "true". This can be switched to "false" to avoid marking the global transaction rollback-only just because a partipating transaction failed. The rollback decision will be on the transaction originator in this case.

However, note that this will only work as long as all participating resources are capable of contiuing towards a transaction commit even after a data access failure: This is generally not the case for a Hibernate Session, for example; neither is it for a sequence of JDBC insert/update/delete operations.

The recommended solution for handling failure of a subtransaction is a "nested transaction", where the global transaction can be rolled back to a savepoint taken at the beginning of the subtransaction. PROPAGATION_NESTED provides exactly those semantics; however, it will only work when nested transaction support is available. This is the case with DataSourceTransactionManager, but not with JtaTransactionManager.

The "globalRollbackOnParticipationFailure" flag will already be available in Spring 1.2.3, which is finally going to be released tonight.

Juergen

[johnzhang]

Thanks a lot, Juergen!

It is a pretty nice solution!