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(a)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(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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev