Atomikos Forum

Wrong read-only optimization


let's consinder class and it's prepare method. If all the participants vote real-only, then the next state is which leads to wrong transaction status javax.transaction.Status.STATUS_UNKNOWN is provided to afterCompletion method of javax.transaction.Synchronization. In my opinion such a behaviuor violates JTA and XA specifications, which state that read-only participant's response is used only for optimization, it should not shadow target state i.e. STATUS_COMMITED or STATUS_ROLLEDBACK.

Best regards,
Alexei Akimov
Alexei Akimov Send private email
Wednesday, July 08, 2009

Thanks - then what do you suggest that the state be?

Guy Pardon Send private email
Friday, July 10, 2009
Let me cite specification first

XA Specification says (2.3.2 Protocol Optimizatiopn, Read-Only):
An RM can respond to the TM’s prepare request by asserting that the RM was not
asked to update shared resources in this transaction branch. This response
concludes the RM’s involvement in the transaction; the Phase 2 dialogue between
the TM and this RM does not occur. The TM need not stably record, in its list of
participating RMs, an RM that asserts a read-only role in the global transaction."

JTA 1.1 Specification says (javax.transaction.Status.STATUS_UNKNOWN):
A transaction is associated with the target object but its current status cannot be determined. This is a transient
condition and a subsequent invocation will ultimately return a different status.

In my opinion it is wrong to consider transaction's status as unknown if transaction has been commited or rolled back successfully. The fact that all participant voted read-only should not affect the final status of transaction. They signal only that it nothing to do on phase 2, so transaction manager should easily complete commit or rollback request and assign correct status to transaction i.e. STATUS_COMMITED or STATUS_ROLLEDBACK depending on the original request. In Atomikos implementation javax.transaction.Synchronization receives STATUS_UNKNOWN during afterCompletion call when transaction manager uses read-only optimization.
Alexei Akimov Send private email
Wednesday, July 15, 2009

Changing this requires changing the core state management - something we will only do for a feature release, not a simple bug fix release. I have scheduled this for a future release (to be determined yet).

Guy Pardon Send private email
Friday, July 24, 2009

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics