Re: [jta-dev] Rationale for preventing registration of a Synchronization

[Michael Musgrove <mmusgrov@xxxxxxxxxx>]

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.

> Where is this reflected in the documentation, though? I don't, for example, see any indication in https://jakarta.ee/specifications/transactions/2.0/apidocs/jakarta/transaction/synchronization#afterCompletion-int-.

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.

On Wed, Jul 3, 2024 at 8:01 PM Laird Nelson <ljnelson@xxxxxxxxx> wrote:

Thanks; makes sense. Where is this reflected in the documentation, though? I don't, for example, see any indication in https://jakarta.ee/specifications/transactions/2.0/apidocs/jakarta/transaction/synchronization#afterCompletion-int-.

On Wed, Jul 3, 2024 at 5:57 AM Michael Musgrove <mmusgrov@xxxxxxxxxx> wrote:

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.

On Mon, Jul 1, 2024 at 4:57 PM Laird Nelson <ljnelson@xxxxxxxxx> wrote:

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?

On Mon, Jul 1, 2024 at 2:20 AM Michael Musgrove <mmusgrov@xxxxxxxxxx> wrote:

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.

On Wed, Jun 26, 2024 at 2:02 AM Laird Nelson via jta-dev <jta-dev@xxxxxxxxxxx> wrote:

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

Red Hat

--

Michael Musgrove

Transactions

Red Hat

--

Michael Musgrove

Transactions

Red Hat