Hmm; I understand that you can't enlist a resource into a transaction that is marked for rollback. That's not my question. I'll try again.
True or false:
1. You can register a Synchronization with an active transaction, mark the transaction for rollback, and the Synchronization's afterCompletion method will still be called when the transaction eventually rolls back. (I assume true.)
True or false:
2. You cannot register a Synchronization with a transaction that is marked for rollback. (I assume true, but this is the nature of my question: why not?)
True or false:
3. You can create an implementation of Synchronization that permits child Synchronizations to be added to it at any point. You can then register that Synchronization with an active transaction, mark the transaction for rollback, and the Synchronization's afterCompletion method will be called. (True if (1) is true.)
Given that (3) is trivial and supported (because of (1)), why is (2) not supported? And where is (2) prohibited in the documentation? (Certainly not in the enlist method, which does not concern Synchronizations.)
I hope that's a little more clear.
Best,
Laird
I forgot to include the group in my previous responses.
> Could you elaborate? I understand this is all hypothetical but why would a Synchronization's afterCompletion method not get called if the Synchronization were registered while the transaction was in a marked-for-rollback state?
We don't write a transaction log if the transaction is going to rollack so after a crash then, on restart, we won't have a record of the transaction so the afterCompletion will not be called. In particular, this would be an issue if the TM and the application are in different JVMs.
It is in the javadoc for the enlist method (
https://jakarta.ee/specifications/platform/9/apidocs/jakarta/transaction/transaction#enlistResource-javax.transaction.xa.XAResource-).
I agree that the first place to look is the spec document since trawling through the API docs is error prone but then again it is good to avoid duplication because of the risk of the two sources diverging.
We don't write a transaction log if the transaction is going to rollack so after a crash then, on restart, we won't have a record of the transaction so the afterCompletion will not be called. In particular, this would be an issue if the TM and the application are in different JVMs.
Could you elaborate? I understand this is all hypothetical but why would a Synchronization's afterCompletion method not get called if the Synchronization were registered while the transaction was in a marked-for-rollback state?
I think it will be because after synchronization callbacks are not guaranteed to be called if the transaction rolls back - if the method was allowed it would give the wrong impression that it will get called.
Hello; what is the rationale for preventing the registration of a synchronization in a transaction/registry that has been marked for rollback?
(Does a transaction that is marked for rollback constitute an "
active transaction context"? I guess it must not here? What "active" means has been
discussed before; sometimes it does mean "active or marked for rollback" but not here apparently.)
I do understand the big picture, i.e. that a Transaction that is marked for rollback is doomed. But is there some actual harm I'm overlooking that registering a synchronization while the Transaction is in this state would incur?
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
--
Michael Musgrove
Transactions
--
Michael Musgrove
Transactions
