Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jta-dev] Rationale for preventing registration of a Synchronization in rollback only state?

Hmm; OK. The registerSynchronization documentation says: "After the transaction is completed, the transaction manager invokes the afterCompletion method." Those are all the words I can find in the javadoc that mention afterCompletion. This, to me, does not appear to say anything about the conditions under which afterCompletion might not be called. Is there somewhere else "in the javadoc, not the main spec", I should be looking?

The TransactionSynchronizationRegistry#registerInterposedSynchronization method also does not seem to say anything about afterCompletion not being called. That was the only other place I could think of. Do you know if there's another?

On Fri, Jul 5, 2024 at 10:41 AM Michael Musgrove <mmusgrov@xxxxxxxxxx> wrote:
To clarify:

You asked "what is the rationale for preventing the registration of a synchronization in a transaction/registry that has been marked for rollback?" and I replied "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".

You followed up with a request for me to elaborate and I responded with "We don't write a transaction log if the transaction is going to rollback 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."

And you then asked where that is stated in the documentation and I replied "it's in the javadoc not the main spec" (admittedly that response included a type which should have said registerSynchronization API method).


On Fri, Jul 5, 2024 at 6:29 PM Michael Musgrove <mmusgrov@xxxxxxxxxx> wrote:


On Fri, Jul 5, 2024 at 5:47 PM Laird Nelson via jta-dev <jta-dev@xxxxxxxxxxx> wrote:
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.

Sorry it was a typo, I meant registerSynchronization(). When you read the spec please also take a look at the javadoc since it adds extra information that might not be clear in the main spec.

Regards


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

On Fri, Jul 5, 2024 at 6:25 AM Michael Musgrove <mmusgrov@xxxxxxxxxx> wrote:
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


--
Michael Musgrove
Transactions


--
Michael Musgrove
Transactions
_______________________________________________
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

Back to the top