Re: [Springframework-developer] Transaction support

[Rod J. <rod...@in...>]

Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations should
behave would also resolve the problem (meaning I could modify the test case,
not the class).

I haven't looked at your code in great detail, but from what I've seen it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've added
explicit programmatic rollback handling, i.e.

if (status != null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of implementing
PlatformTransactionManager directly, a transaction manager implementation
can benefit from the former's programmatic rollback and propagation behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?