Re: [hibernate-dev] JTA synchronizations on WildFly
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(a)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/jbos...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev