Juerge,
In JTATransactionManager, you've got:
protected boolean isExistingTransaction(Object transaction) {
try {
int status = ((UserTransaction) transaction).getStatus();
return (status != Status.STATUS_NO_TRANSACTION && status !=
Status.STATUS_MARKED_ROLLBACK);
}
catch (SystemException ex) {
throw new TransactionSystemException("JTA failure on
getStatus", ex);
}
}
I'm wondering why you lumped together STATUS_NO_TRANSACTION and
STATUS_MARKED_ROLLBACK.
In some code I'm running, inside an EJB demarcated transaction, a
third-party EJB did a setRollbakOnly() on it's context. Then in a
subsequent step, still inside that rollback-marked exception, my spring
based code tried to execute something through a transactionally wrapped
POJO. What happened is that Spring then thought (because of the above
code) that there was no transaction, and tried to initiate one. At that
point I got an exception from the JBoss Transaction Manager that it
didin't support nested transactions. Now in this case, either way
everything fails. But I think it would be more correct to treat the
marked for rollback case as 'there is an existing transaction'. If the
JTA Transaction manager in the container actually supported nested
transactions, the above code would allow the spring code to execute in a
new tranasaction, when it in fact should just join the (marked for
rollback) existing transaction.
Regards,
Colin
|
