[jboss-as7-dev] Switch to use TransactionSynchronizationRegistry.registerInterposedSynchronization?

[Scott Marlow]

Okay, lets move forward on this change.

I think the first part of the change, will be in IJ.  I'll help with a 
IJ patch to get the ball rolling forward.  My current understanding is 
that the patch won't be easily testable with AS 7.0 until the IJ trunk 
is synced with AS 7.0 again (targeting around June13-14th).

We also need to change our EE JPA subsystem's integration with 
Hibernate, to register Hibernate's JPA sync with the TSR instead of TX. 
  This is a small change.

Infinispan should just work (from conversations on Infinispan-dev ml.

EJB3.1 is already expecting to use TSR for registering syncs (the 
expected impact of these changes being that some tests will start to pass.)

Are there any other changes needed that I'm leaving out?

On 06/02/2011 03:51 PM, Jason T. Greene wrote:
> To me the answer seems clear cut. TSR is exposed to EE applications and
> libs due to spec requirements. The TM is not. So we should convert
> everything to TSR.
>
> On 6/2/11 8:23 AM, Jonathan Halliday wrote:
>>
>> On 06/02/2011 01:41 PM, Scott Marlow wrote:
>>
>>> My understanding of "Too late in the game", would be attempting to
>>> register the sync after commit has been called to start ending the
>>> transaction.
>>
>> That's not quite right and indeed the trouble we're seeing stems from
>> Synchronizations that (indirectly) register other Synchronizations from
>> within beforeCompletion i.e. at a point in time after commit() is called
>> by the app or container and the transaction manager has thus begun tx
>> termination processing, of which beforeCompletion calls are one of the
>> early parts.
>>
>> Since the tx is technically still active during beforeCompletion, it is
>> legitimate for beforeCompletions to call registerSynchronization or
>> registerInterposedSynchronization. Prior to the introduction of the
>> latter method in JTA 1.1 that was the end of the story - newly
>> registered Syncs just got tacked onto the end of the pending list and
>> the beforeCompletion phase continued to run until no new ones were
>> registered. Registration order determined call order, although that's
>> not a JTA requirement, just an impl detail.
>>
>> With JTA 1.1 there is now a spec defined partial order for
>> Synchronizations which differs from registration order, so in some cases
>> we can't simply tack newly registered ones onto the list - we're passed
>> the point at which we would call them and so we reject the registration.
>>
>> A beforeCompletion can only register a Sync only if it would be ordered
>> after the one that's currently executing. Technically this is true even
>> within Sync types, but it only manifests as a problem between types
>> (interposed/non-interposed) as we take care of the ordering between
>> instances of the same type internally in the tx code - you can't
>> override that bit through the JTA api.
>>
>> So, the rule for activity in beforeCompletion is:
>>
>> - a Sync registered via registerSynchronization may call either
>> registerSynchronization or registerInterposedSynchronization.
>>
>> - a Sync registered via registerInterposedSynchronization may call
>> only registerInterposedSynchronization.
>>
>> Thus hibernate (interposed) can't call the JCA (non-interposed) to get a
>> db connection. But it could call registerInterposedSynchronization,
>> which is basically why there is now a more to convert everything that it
>> may call to use interposed syncs. That escalation may not necessarily
>> be the best long term move, as it leaves you with a problem if you wind
>> up needing a yet tighter defined ordering equivalent to
>> registerInterposedInterposed...
>>
>> Jonathan.
>>
>>>
>>> Note from Jonathan Halliday about the same:
>>> "
>>> per the JTA spec, interposed Synchronizations must be called after
>>> non-interposed ones. Since hibernate is using interposed
>>> Synchronizations, the tx has already passed the point at which it can
>>> call non-interposed Synchronizations. Therefore it does not allow them
>>> to be registered, on the basis that there needs to be some way to spot
>>> that they are not going to get called, otherwise you'd spend hours
>>> scratching your head and wondering why the Synchronization was not
>>> getting invoked. There is a corner case where you don't give a toss
>>> about beforeCompletion and want the Synchronization only for
>>> afterCompletion, but there is no way in the API to indicate that so we
>>> play it safe and disallow uniformly.
>>
>>
>
>