[hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

I just saw the below email response after I sent the last one.  Sorry 
about that, will respond here also.  :)

On 03/10/2015 09:14 AM, Emmanuel Bernard wrote:
> Ah synchronization ordering, it never gets old :) Steve might remember better but I don’t think we ever managed to convice the tx team to offer guaranteed ordering.

We started discussing synchronization ordering as well (within the 
interposed group) and there is a WildFly specific code change being 
worked on to always run the JCA sync last (so IronJacamar can delist a 
resource that would of otherwise been leaked).

>
> Your workaround seems fine (if there is a JtaPlaform) but when we add more logic to your onRollback calls, we might want to offer access tot he Session to try compensating for example. In which case, we would be in trouble with the closed session. I don’t have a good idea.

Hmm, for the new SPI that deals with registering "concurrency safe" 
OnRollback calls, I wonder if we should have an ordering priority, so 
that the session clear/OGM operations list presentation, can always run 
before the JPA container closes the session.  In a discussion about 
changing the TM level Sync ordering for an unknown set of Syncs, we 
talked about specifying an ordering priority for registered Syncs, that 
idea will probably be useful for ordering the OnRollback calls if we 
enable that.

>
> I am a bit surprised WildFly closes the session but that might be per spec that the container manages these calls.

Yes, only for a transaction scoped entity manager, do we have to close 
the session after the transaction ends.  We don't do this for 
application managed (application needs to call EM.close()).  For 
extended persistence contexts, we close the session, after the last 
referencing stateful bean is destroyed (tracking is done in the JPA 
container).

Scott

>
>> On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> I'm trying to perform a specific action upon transaction rollback.
>>
>> Assuming this could be done using a custom
>> javax.transaction.Synchronization, I tried to register a synchronization as
>> follows:
>>
>>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>     transaction.registerSynchronization( new MySync() );
>>
>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>> never is. I debugged this a bit on WildFly and observed the following:
>>
>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> RegisteredSynchronization manages (indirectly, through
>> TransactionCoordinator, SynchronizationRegistry etc.) those
>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>> * WildFly (specifically, TransactionUtil [1]) registers its own
>> SessionSynchronization
>> for closing the entity manager/session
>>
>> Now that second synchronization is called first, closing the session. Upon
>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> afterComplection() is called on RegisteredSynchronization afterwards, any
>> previously registered delegate synchronizations are gone already and thus
>> do not get invoked.
>>
>> I believe I found a workaround for my case by registering my
>> synchronization through JtaPlatform#registerSynchronization() (which
>> registers it with the actual JTA transaction).
>>
>> My questions are:
>>
>> * Is this behaviour expected?
>> * Is the work-around of doing the registration via JtaPlatform viable or
>> are there any drawbacks which I'm not aware of?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>