12:14 p.m.
For some reason I'm seeing though JBossStandAloneJtaPlatform being used
when debugging an OGM integration test on WildFly.
WF's JtaPlatform seems not to be picked up. Tried to debug a but,
apparently it never comes to the point where JipiJapa would inject the
JBossAppServerJtaPlatform as platform. I could imagine it's due to OGM
being used as persistence provider, so maybe the right implicit module
dependencies don't get added? Scott?
It's all a bit guess work on my side, I don't know that WF/JipiJapa code
very well.
2015-03-10 16:50 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
Gunnar, WildFly uses its own JtaPlatform...
On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> Hi,
>
> > I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization() on WildFly, is registering your
> synchronization as interposed via the TransactionSynchronizationRegistry
> [2].
>
> That seems not to be the case. If you check out AbstractJtaPlatform and
> TransactionManagerBasedSynchronizationStrategy in ORM,
> registerSynchronization() adds the Sync as non-interposed via
> TransactionManager.getTransaction().registerSynchronization().
>
> But the ordering is indeed what makes me wonder. As SessionSynchronization
> is interposed, the non-interposed beforeCompletion() hooks are run, but
> the
> non-interposed afterCompletion() hooks managed via
> RegisteredSynchronization are never run, as the session has been closed
> and
> thus the list of syncs to be invoked through RegisteredSynchronization has
> been cleared at this point. At least this behaviour was surprising to me.
>
> My work-around works because my non-interposed sync is added through
> JtaPlatform to the actual (Arjuna) Transaction instance directly (rather
> than indirectly via RegisteredSynchronization) and thus gets invoked
> properly.
>
> 2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow(a)redhat.com>:
>
> > Hi Gunnar,
> >
> > Yes, this behaviour is expected since you registered an non-interposed
> > synchronization. For what purpose are you registering the transaction
> > synchronization? I would like to be aware of the synchronizations that
> we
> > register in WildFly.
> >
> > The non-interposed sync beforeCompletion callback are invoked first,
> then
> > the interposed sync beforeCompletion calls, then the interposed
> > afterCompletion(int status) calls and finally, the non-interposed
> > afterCompletion(int status) calls.
> >
> > The Synchronizations that are registered via the javax.transaction.
> >
>
TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
> > [2] are interposed.
> >
> > Synchronizations that are registered via the
> javax.transaction.Transaction.
> > registerSynchronization(Synchronization) [3] are non-interposed.
> >
> > In WildFly, the transaction manager uses the registration order within
> the
> > interposed/non-interposed group. Before completion syncs (within their
> > respective group), are run in registration order. After completion
> syncs
> > (within their respective group), are run in reverse registration order.
> >
> > I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization()
> > on WildFly, is registering your synchronization as interposed via the
> > TransactionSynchronizationRegistry [2]. There might be a way to register
> > a sync callback at the Hibernate session level (which would also run as
> > interposed sync on WildFly).
> >
> > Not sure if you saw my email yesterday to Hibernate-dev ml. You should
> be
> > aware that the afterCompletion(int status) callback, may be called from
> a
> > non-application thread when the WildFly tm reaper handles tx timeout
> (this
> > can happen while the application thread is still invoking calls on the
> > Hibernate session). Because the Hibernate session is not thread safe,
> we
> > need to ensure that the Hibernate session afterCompletion(int status)
> > callback does not mutate the Hibernate session (e.g. calling
> > session.clear() what status == rolled back).
> >
> > Scott
> >
> > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/
> > TransactionSynchronizationRegistry.html#registerInterposedSynchronizat
> > ion%28javax.transaction.Synchronization%29
> >
> > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/
> > Transaction.html#registerSynchronization%28javax.transaction.
> > Synchronization%29
> >
> >
> > On 03/10/2015 09:03 AM, Gunnar Morling 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(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
>