[jboss-as7-dev] Switch to use TransactionSynchronizationRegistry.registerInterposedSynchronization?
Scott Marlow
smarlow at redhat.com
Tue Jun 7 10:59:03 EDT 2011
On 06/02/2011 09: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.
I'm trying to understand what the registerInterposedSynchronization
"special ordering semantics" means. I understand it at least means,
that registerInterposedSynchronization syncs run after
registerSynchronization syncs. Does it also mean that the
registerInterposedSynchronization syncs are (creation) ordered as well?
Internally, do we currently use a (creation) ordered list for the
registerInterposedSynchronization? I'm not asking to change the
contract, just trying to understand more.
>
> 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.
>
>
More information about the jboss-as7-dev
mailing list