[hibernate-dev] JTA synchronizations on WildFly

[Emmanuel Bernard]

That's a good question. For now we implicitly decided not to use a different tx I guess. Remember, there in no actual transaction in those NoSQL backends in the first place. 


> On 10 mars 2015, at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Isn't the general approach is for "compensating actions" to be run in a separate transaction?
> 
>> On Tue, Mar 10, 2015 at 10:11 AM, Scott Marlow <smarlow at redhat.com> wrote:
>> 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
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>