4:09 p.m.
On 06/02/2011 09:50 AM, Mircea Markus wrote:
On 2 Jun 2011, at 13:19, Scott Marlow wrote:
> On 06/02/2011 05:31 AM, Mircea Markus wrote:
>>
>> On 1 Jun 2011, at 20:49, Scott Marlow wrote:
>>
>>> I posted a message on the as7-dev ml
>>> (http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html),
>>> about switching to use the TransactionSynchronizationRegistry.
>>>
>>> Does Infinispan currently register Transaction synchronization objects?
>> yes
>>> Does Infinispan currently register synchronizations via
>>> TransactionSynchronizationRegistry (TSR)?
>> no, we register synchronizations through transaction.registerSynchronization
>>>
>>> I'm trying to get a sense for, what would happen if container managed
>>> (AS7) session beans were registered with the active JTA transaction via
>>> the TSR.
>>>
>>> If AS7 switches to use the TSR, I think that Infinispan might need to
>>> ensure that it doesn't attempt to register with the TX too late.
>> right. One way to go is by making the registration code pluggable.
>
> I should point out that I believe its only a problem, to call
Transaction.registerSynchronization() after the point, where the ordering cannot be
correct. However, no such checking is performed if no components are registering their
syncs via TransactionSynchronizationRegistry.
>
> So, another question, how likely would it be, that an application would see
Infinispan registering a sync via Transaction.registerSynchronization(), after the
transaction commit has been initiated?
ATM Infinispan allows the registration if the transaction is in one of the following
states: Status.STATUS_ACTIVE || Status.STATUS_PREPARING. If tx is in any other state the
sync won't be registered and a exception is instead sent to the user.
>
> If Transaction.registerSynchronization() will always be called by Infinispan before
the transaction commits. We shouldn't have to be as concerned about support for
registering the Infinispan syncs with TransactionSynchronizationRegistry.
>
> If the answer is we aren't sure or Transaction.registerSynchronization() could
happen after the transaction commit has been started, we should have it be pluggable.
From Jonathan's comment[1] I understand that "interposed Synchronizations must
be called after non-interposed ones". That seems to be true disregarding tx's
status. Or am I wrong?
Jonathan also commented here a few minutes ago, with further
clarification of the exact rules. Best to read what he said directly
(he described the situation in much better detail than me).
http://lists.jboss.org/pipermail/jboss-as7-dev/2011-June/002275.html
Copying from his email:
"
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.
"
Once the sync registered via TSR.registerInterposedSynchronization() has
been invoked, its too late to attempt registering further syncs via
TX.registerSynchronization(), which is what we were orchestrating before
when Hibernate's TSR.registerInterposedSynchronization() registered
sync, trying to get a database connection from the AS7 managed
connection pool (which tried to do a TX.registerSynchronization()).
The point of all my emails about this, is to investigate if we can use
TSR.registerInterposedSynchronization in the AS7 EE containers, without
causing other components to fail. Also, I'm trying to understand
how/when we could switch over to use
TSR.registerInterposedSynchronization(), while avoiding such failures.