Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jta-dev] OK to suspend() if marked for rollback?



On Sun, 17 Mar 2024 at 11:40, Michael Musgrove via jta-dev <jta-dev@xxxxxxxxxxx> wrote:
> I hope this is a sensible question. I'm addressing it to this list rather than (say) narayana-users because it concerns the jakarta.transaction.TransactionManager interface. (I saw no "jta-users" list.)

It is a sensible question and is appropriate for this list.

> Suppose TransactionManager#begin() is called on the current thread.

> Suppose next TransactionManager#setRollbackOnly() is called on the same thread. Obviously now ultimately this transaction's outcome can only be rollback.

> Suppose next TransactionManager#suspend() is called on the same thread.

> Is this a legal call? Can you suspend a transaction that is marked for rollback?

Yes, it is allowed by the JTA spec; the javadoc signature does not include RollbackException, only SystemException (if there is an unexpected error condition).

(Note that you cannot do any further work on currently enlisted resources nor enlist new resources for this rollback only transaction since any such changes would be rolled back).

XAResource#isSameRM is part of the discussion here since the TM calls suspend and resume on resources that report that they represent the same underlying resource (to ensure that <quote>the same RM only receives one set of prepare-commit calls for the transaction<end quote>). But for the usual case we do not call suspend (TMSUSPEND) and resume (TMRESUME) on new transaction branches, which is your case - so the fine detail of xa_end and xa_start don't apply (if they did then "Chapter 6 State Tables" in the XA spec and  "Table 6-4 State Table for Transaction Branches" in the XA spec is a good section to study).

> Assuming you can, then assume a new transaction is started and committed. (I assume that's possible?)

Yes it is possible to associate a different transaction with the thread provided the thread is not already associated, which it won't be since your scenario says TransactionManager#suspend() has been called.

> Suppose next TransactionManager#resume(...) is called with the Transaction representing the suspended-and-marked-for-rollback transaction.

As long as the call doesn't result in, and is not followed by, a call to enlistResource() then this is ok, otherwise it would fail since the javadoc says the following would be thrown:

  "RollbackException - Thrown to indicate that the transaction has been marked for rollback only."

> Are we still in a legal state? (I understand this transaction's only outcome will be rollback.) Or was there an illegal state in there somewhere? I…guess it's OK to do suspension and resumption even when you know everything is going to ultimately blow up? Or…?

The branch should still be in the "Rollback Only" state after the transaction has been re-associated (remark: the TM uses the thread to do the association and the RM uses the branch id to associate work with calls). I would not say blow up since rollback is a valid outcome.

Tom may have some further, hopefully not alternate, insights on your question.

Thank you for the answers!

The only other thing I would like to add is to point out to Laird is to consider the generaly use of TransactionManager because: "The jakarta.transaction.TransactionManager interface allows the application server to control transaction boundaries on behalf of the application being managed" (https://jakarta.ee/specifications/transactions/2.0/jakarta-transactions-spec-2.0.html#transactionmanager-interface). The point being TransactionManager is intended for use by the application server rather than end user code, and perhaps this is application server code that Laird is asking in regards but mentioning it here for consideration.
 

On Fri, Mar 8, 2024 at 11:56 PM Laird Nelson via jta-dev <jta-dev@xxxxxxxxxxx> wrote:
I hope this is a sensible question. I'm addressing it to this list rather than (say) narayana-users because it concerns the jakarta.transaction.TransactionManager interface. (I saw no "jta-users" list.)

Suppose TransactionManager#begin() is called on the current thread.

Suppose next TransactionManager#setRollbackOnly() is called on the same thread. Obviously now ultimately this transaction's outcome can only be rollback.

Suppose next TransactionManager#suspend() is called on the same thread.

Is this a legal call? Can you suspend a transaction that is marked for rollback?

Assuming you can, then assume a new transaction is started and committed. (I assume that's possible?)

Suppose next TransactionManager#resume(...) is called with the Transaction representing the suspended-and-marked-for-rollback transaction.

Are we still in a legal state? (I understand this transaction's only outcome will be rollback.) Or was there an illegal state in there somewhere? I…guess it's OK to do suspension and resumption even when you know everything is going to ultimately blow up? Or…?

Best,
Laird


_______________________________________________
jta-dev mailing list
jta-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev


--
Michael Musgrove
Transactions
_______________________________________________
jta-dev mailing list
jta-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev

Back to the top