Re: [hibernate-dev] Jira issues

[Hardy Ferentschik]

On Mon, Mar 09, 2015 at 09:26:34PM -0500, Steve Ebersole wrote:
> I tried using the feedback approach with Atlassian, lets see how that goes
> and whether we hear back.  If I don't hear back in a few days, I will reach
> out to them directly.

+1 I guess this is related to their latest changes. Maybe there was more to it
than some simple UI changes?

--Hardy 


pgpKgBA5QvSL6.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] JTA synchronizations on WildFly

[Gunnar Morling]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

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#registerInterposedSynchronization%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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Emmanuel Bernard]

So Gunnar, your workaround is fine today but will pose problems in the future 
if we decide that onRollback for ErrorHandler needs access to the session 
somehow to be able to compensate and undo the already executed operations:
- a closed session will do us no good
- there is a harder problem that Scott mentions below related to tx reaping in 
a different thread

Let’s try and find a solution for the first problem.

@Scott, I think what happens is the following:

- Hibernate registers a Sync when the EM is created (for the flush() callbacks 
and a few other things)
- Synchronization attached to the Hibernate Transaction objects are 
piggybacking on that initial Sync attachement
- Wildfly attach a “close session” Sync once it has the instance of 
EntityManager
- according to your rules, the close session afterTransaction Sync is called 
before the one Hibernate put
- that explains why Gunnar finds an already closed Tx.

But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator 
creates the Hibernate transaction, which is when the EM is created, I can’t 
explain why the workaround works.

Emmanuel

> On 10 Mar 2015, at 14:39, Scott Marlow  wrote:
> 
> 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#registerInterposedSynchronization%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
>> synchron

Re: [hibernate-dev] JTA synchronizations on WildFly

[Emmanuel Bernard]

Scott, for Hibernate OGM and for non transactional datastores, we collect the 
list of executed operations and offer the list if the user calls Hibernate’s 
transaction.rollback() or if the JTA transaction is rollbacked. Note that the 
JTA transaction has no resource attached to it since the datastore is non 
transactional, we just piggyback on the begin / commit lifecycle without their 
true semantic.
This feature is called the ErrorHandling or Compensation API in OGM. That’s why 
we want to attach a Synchronization.

> On 10 Mar 2015, at 14:39, Scott Marlow  wrote:
> 
> 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#registerInterposedSynchronization%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@lists.jboss.org
>> https://lists.jboss.org/mailman/

Re: [hibernate-dev] JTA synchronizations on WildFly

[Emmanuel Bernard]

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.

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.

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

> On 10 Mar 2015, at 14:03, 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

On 03/10/2015 10:12 AM, Emmanuel Bernard wrote:
> So Gunnar, your workaround is fine today but will pose problems in the future 
> if we decide that onRollback for ErrorHandler needs access to the session 
> somehow to be able to compensate and undo the already executed operations:
> - a closed session will do us no good
> - there is a harder problem that Scott mentions below related to tx reaping 
> in a different thread
>
> Let’s try and find a solution for the first problem.
>
> @Scott, I think what happens is the following:
>
> - Hibernate registers a Sync when the EM is created (for the flush() 
> callbacks and a few other things)
> - Synchronization attached to the Hibernate Transaction objects are 
> piggybacking on that initial Sync attachement
> - Wildfly attach a “close session” Sync once it has the instance of 
> EntityManager
> - according to your rules, the close session afterTransaction Sync is called 
> before the one Hibernate put
> - that explains why Gunnar finds an already closed Tx.
>
> But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator 
> creates the Hibernate transaction, which is when the EM is created, I can’t 
> explain why the workaround works.

Because Gunnar initially registered the Sync, via [3] 
javax.transaction.Transaction.registerSynchronization(Sync), which might 
be correct in some non-WildFly environments where perhaps all Syncs are 
registered via [3] (as non-interposed syncs).  When Gunnar, switched to 
the Hibernate JtaPlatform mechanism for registering the Sync, we then 
switched to an interposed Sync.  I suspect that the JtaPlatform sync 
registration is a good way to register the OGM, however, I have been 
told that the *best* way is to register only one sync (to avoid ordering 
issues).

If OGM could register to share the existing Hibernate EM sync, we would 
have more control over when the OGM sync is invoked and in which thread 
(application versus background tm reaping thread).

Regarding the proposed "new proposal for tx timeout handling using 
transaction DISASSOCIATING event notification" discussion and how that 
could impact OGM.  We will continue to run the interposed/non-interposed 
sync callbacks in whatever thread the TM, calls them from (e.g. 
beforeCompletion may or may not be called from app thread, 
afterCompletion will be called from either app thread, background 
reaping thread or background communications thread).  The reason is that 
certain resources need to be cleaned up immediately from the 
Sync.afterCompletion(int status) call.  Certain other resources (like 
clearing managed entities from persistence context after a rollback), 
need to be handled from either the application thread or a background 
thread after the application thread is disassociated from the JTA 
transaction.

IMO, the OGM ErrorHandling/Compensation API probably needs to be aware 
of the same concurrency requirements to avoid presenting the executed 
operations list, while the application thread is still executing new 
operations (because it perhaps doesn't yet know that the tx rolled back).

It would be good to know if OGM will also need the concurrency 
protection, so that any new Hibernate 5.0 SPI can be used by OGM (e.g. 
currently the only need is to run the Hibernate Session.clear when we 
know that the application thread is not actively using the Session).

>
> Emmanuel
>
>> On 10 Mar 2015, at 14:39, Scott Marlow  wrote:
>>
>> 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

Re: [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  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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Steve Ebersole]

On Tue, Mar 10, 2015 at 8:39 AM, Scott Marlow  wrote:
>
>
> 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).


If you register syncs via the Hibernate Transaction API
(session.getTransaction().registerSynchronization()) these will be kept
local to the Session.  They are then delegated to in response to all
transaction events, whether that comes from a Transaction API call or JTA
sync callback.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Gunnar Morling]

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 :

> 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#registerSynchronizati

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

On 03/10/2015 11:44 AM, Steve Ebersole wrote:
> Scott, I am not following.  Pardon me if I am being dense :)
>
> Today, in our afterCompletion hooks we have code that, in the case of
> rollback, tries to make a determination of whether the rollback is due
> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
> then we delay the afterCompletion processing.

Currently, in our afterCompletion hooks, the determining code isn't 
aware of the current/last application thread id.  I think that we are 
only tracking the first thread id that is used with the Hibernate 
session but not the last thread id.

>
> So how, specifically, would this be different in what you propose?

The new approach will not use thread id, instead in our afterCompletion 
call, we will have the TM level knowledge, of whether the application 
thread has called tx rollback/suspend/commit yet.  If the application 
thread has called tx rollback/suspend/commit already, the 
afterCompletion call can safely clear managed entities from the session 
without violating concurrency concerns.  If the application has not yet 
called tx rollback/suspend/commit yet, we need to defer the clearing of 
the Hibernate session, until the TM listener calls us back, to let us 
know that the application has called tx rollback/suspend/commit, at 
which time we can safely clear the Hibernate session without violating 
(Hibernate session) concurrency concerns.

>
> Are you saying that with this listener approach, that the listener would
> be notified of disassociation prior to the afterCompletion callback on
> our RegisteredSynchronization?  But in the timeout case, the
> disassociation would happen later?

Yes.  It is also possible that in the timeout case, that the 
disassociation will come first (e.g. if there is a race between the app 
committing the transaction and the reaper thread timing out) but more 
likely that the disassociation comes later for the timeout case.

FYI, the TM level SPI changes [4][5] are still open for review.

Scott

[4] https://github.com/jbosstm/jboss-transaction-spi/pull/5
[5] https://github.com/jbosstm/narayana/pull/810

>
> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow  > wrote:
>
> With a proposed TM level listener, we will have an SPI for notification
> of when application threads associated with a JTA transaction, become
> disassociated with the transaction (tm.commit/rollback/suspend time).
> Having this knowledge in a synchronization callback, can determine
> whether the persistence context should be cleared directly from the
> Synchronization.afterCompletion(int) call or should be deferred until
> the transaction is disassociated from the JTA transaction.
>
> This idea is based on a TM level listener approach that Tom Jenkinson
> [1] suggested.  Mike Musgrove has a "proof of concept" implementation of
> the suggested changes [2].  I did some testing with [3] to see if the
> improvement helps with clearing entities that might still be in the
> persistence context after a background tx timeout.
>
> I'm wondering if in the Hibernate ORM
> Synchronization.afterCompletion(int status) implementation, in case of
> tx rollback, if we could defer the clearing of the Hibernate session to
> be handled by the JtaPlatform.  This could be setup at
> EntityManager.joinTransaction() time (if a new property like
> "hibernate.transaction.defer_clear_session" is true).  Perhaps via a
> JtaPlatform.joinTransaction(EntityManager) registration call?
>
> Thoughts?
>
> Scott
>
> [1] https://developer.jboss.org/thread/252572?start=45&tstart=0
>
> [2]
> 
> https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/
>
> [3]
> 
> https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Emmanuel Bernard]

I think we would need the same concurrency protection yes. If not today, in the 
near future. 


> On 10 mars 2015, at 15:53, Scott Marlow  wrote:
> 
> 
> 
>> On 03/10/2015 10:12 AM, Emmanuel Bernard wrote:
>> So Gunnar, your workaround is fine today but will pose problems in the 
>> future if we decide that onRollback for ErrorHandler needs access to the 
>> session somehow to be able to compensate and undo the already executed 
>> operations:
>> - a closed session will do us no good
>> - there is a harder problem that Scott mentions below related to tx reaping 
>> in a different thread
>> 
>> Let’s try and find a solution for the first problem.
>> 
>> @Scott, I think what happens is the following:
>> 
>> - Hibernate registers a Sync when the EM is created (for the flush() 
>> callbacks and a few other things)
>> - Synchronization attached to the Hibernate Transaction objects are 
>> piggybacking on that initial Sync attachement
>> - Wildfly attach a “close session” Sync once it has the instance of 
>> EntityManager
>> - according to your rules, the close session afterTransaction Sync is called 
>> before the one Hibernate put
>> - that explains why Gunnar finds an already closed Tx.
>> 
>> But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator 
>> creates the Hibernate transaction, which is when the EM is created, I can’t 
>> explain why the workaround works.
> 
> Because Gunnar initially registered the Sync, via [3] 
> javax.transaction.Transaction.registerSynchronization(Sync), which might be 
> correct in some non-WildFly environments where perhaps all Syncs are 
> registered via [3] (as non-interposed syncs).  When Gunnar, switched to the 
> Hibernate JtaPlatform mechanism for registering the Sync, we then switched to 
> an interposed Sync.  I suspect that the JtaPlatform sync registration is a 
> good way to register the OGM, however, I have been told that the *best* way 
> is to register only one sync (to avoid ordering issues).
> 
> If OGM could register to share the existing Hibernate EM sync, we would have 
> more control over when the OGM sync is invoked and in which thread 
> (application versus background tm reaping thread).
> 
> Regarding the proposed "new proposal for tx timeout handling using 
> transaction DISASSOCIATING event notification" discussion and how that could 
> impact OGM.  We will continue to run the interposed/non-interposed sync 
> callbacks in whatever thread the TM, calls them from (e.g. beforeCompletion 
> may or may not be called from app thread, afterCompletion will be called from 
> either app thread, background reaping thread or background communications 
> thread).  The reason is that certain resources need to be cleaned up 
> immediately from the Sync.afterCompletion(int status) call.  Certain other 
> resources (like clearing managed entities from persistence context after a 
> rollback), need to be handled from either the application thread or a 
> background thread after the application thread is disassociated from the JTA 
> transaction.
> 
> IMO, the OGM ErrorHandling/Compensation API probably needs to be aware of the 
> same concurrency requirements to avoid presenting the executed operations 
> list, while the application thread is still executing new operations (because 
> it perhaps doesn't yet know that the tx rolled back).
> 
> It would be good to know if OGM will also need the concurrency protection, so 
> that any new Hibernate 5.0 SPI can be used by OGM (e.g. currently the only 
> need is to run the Hibernate Session.clear when we know that the application 
> thread is not actively using the Session).
> 
>> 
>> Emmanuel
>> 
>>> On 10 Mar 2015, at 14:39, Scott Marlow  wrote:
>>> 
>>> 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
>>> JtaPl

Re: [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  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  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  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@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernat

Re: [hibernate-dev] JTA synchronizations on WildFly

[Gunnar Morling]

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 :

> Gunnar, WildFly uses its own JtaPlatform...
>
> On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling 
> 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 :
>>
>> > 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(

Re: [hibernate-dev] JTA synchronizations on WildFly

[Steve Ebersole]

Ah, that could be.  Jipijapa does do a lot of things specific to the
provider used.  Probably we just need some proper OGM Jipijapa hooks.

On Tue, Mar 10, 2015 at 12:14 PM, Gunnar Morling 
wrote:

> 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 :
>
>> Gunnar, WildFly uses its own JtaPlatform...
>>
>> On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling 
>> 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 :
>>>
>>> > 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.
>>> >>
>>> >> 

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

On 03/10/2015 12:30 PM, Steve Ebersole wrote:
> You confused me more :)
>
> One the one had you say that we will use this fact of whether the
> transaction has been disassociated to indicate whether the transaction
> is completing normally (disassociated == true) or timed-out
> (disassociated == false).  But at the same time you are saying that it
> is quite possible that we could still receive the
> afterCompletion callback in the timed-out case and have (disassociated
> == true) due to race conditions.

When we have both disassociated == true and afterCompletion has been 
called, then it is safe to clear the Hibernate session.  The order that 
these conditions are detected, does not matter.

>
> So what is this buying us?
>
>
> On Tue, Mar 10, 2015 at 11:09 AM, Scott Marlow  > wrote:
>
>
>
> On 03/10/2015 11:44 AM, Steve Ebersole wrote:
>
> Scott, I am not following.  Pardon me if I am being dense :)
>
> Today, in our afterCompletion hooks we have code that, in the
> case of
> rollback, tries to make a determination of whether the rollback
> is due
> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
> then we delay the afterCompletion processing.
>
>
> Currently, in our afterCompletion hooks, the determining code isn't
> aware of the current/last application thread id.  I think that we
> are only tracking the first thread id that is used with the
> Hibernate session but not the last thread id.
>
>
> So how, specifically, would this be different in what you propose?
>
>
> The new approach will not use thread id, instead in our
> afterCompletion call, we will have the TM level knowledge, of
> whether the application thread has called tx rollback/suspend/commit
> yet.  If the application thread has called tx
> rollback/suspend/commit already, the afterCompletion call can safely
> clear managed entities from the session without violating
> concurrency concerns.  If the application has not yet called tx
> rollback/suspend/commit yet, we need to defer the clearing of the
> Hibernate session, until the TM listener calls us back, to let us
> know that the application has called tx rollback/suspend/commit, at
> which time we can safely clear the Hibernate session without
> violating (Hibernate session) concurrency concerns.
>
>
> Are you saying that with this listener approach, that the
> listener would
> be notified of disassociation prior to the afterCompletion
> callback on
> our RegisteredSynchronization?  But in the timeout case, the
> disassociation would happen later?
>
>
> Yes.  It is also possible that in the timeout case, that the
> disassociation will come first (e.g. if there is a race between the
> app committing the transaction and the reaper thread timing out) but
> more likely that the disassociation comes later for the timeout case.
>
> FYI, the TM level SPI changes [4][5] are still open for review.
>
> Scott
>
> [4] https://github.com/jbosstm/__jboss-transaction-spi/pull/5
> 
> [5] https://github.com/jbosstm/__narayana/pull/810
> 
>
>
> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow  
> >> wrote:
>
>  With a proposed TM level listener, we will have an SPI for
> notification
>  of when application threads associated with a JTA
> transaction, become
>  disassociated with the transaction
> (tm.commit/rollback/suspend time).
>  Having this knowledge in a synchronization callback, can
> determine
>  whether the persistence context should be cleared directly
> from the
>  Synchronization.__afterCompletion(int) call or should be
> deferred until
>  the transaction is disassociated from the JTA transaction.
>
>  This idea is based on a TM level listener approach that Tom
> Jenkinson
>  [1] suggested.  Mike Musgrove has a "proof of concept"
> implementation of
>  the suggested changes [2].  I did some testing with [3] to
> see if the
>  improvement helps with clearing entities that might still
> be in the
>  persistence context after a background tx timeout.
>
>  I'm wondering if in the Hibernate ORM
>  Synchronization.__afterCompletion(int status)
> implementation, in case of
>  tx rollback, if we could defer the clearing of the
> Hibernate session to
>  be handled by the JtaPlatform.  This could be setup at
>  EntityManager.joinTransaction(__) t

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

>
> So what is this buying us?
>

The current Hibernate ORM thread id checking, does not properly handle 
the case when the application thread changes between calls to the 
Hibernate session.  The new approach does handle the application thread 
changing between session invocations and also covers a few other cases 
as well (like clearing the persistence context after the application may 
of added another entity after the background thread rolled back the 
transaction).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

Not exactly sure but this might be the way that Jipijapa registers the 
JtaPlatform.  Originally, Jipijapa used the service approach but 
reverted that due to a memory leak (I think in envers?).

This was mentioned a while back via [3].  I think we talked about 
switching Jipijapa back to using a 
META-INF/services/org.hibernate.engine.transaction.jta.platform.spi.JtaPlatformProvider
 
but I never bothered since the current non-service approach works 
(except for your use case :).

Scott

[3] http://lists.jboss.org/pipermail/hibernate-dev/2013-July/010140.html

On 03/10/2015 01:14 PM, Gunnar Morling wrote:
> 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  >:
>
> Gunnar, WildFly uses its own JtaPlatform...
>
> On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling
> mailto:gun...@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  >:
>
>  > 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 afterCo

[hibernate-dev] Master

[Steve Ebersole]

I wanted to given everyone a heads up that I just pushed the work I have
been doing up to master.  It is alot.  It covers most of what was planned
as required for 5.0.  The only outstanding item from that initial work is
to integrate the changes into Envers, but I was still waiting to hear back
from Adam and Lukasz about some design questions before proceeding with
that[1].

The main work involved:
1) breaking up Configuration into the bootstrap APIs we have been
discussing.  Configuration is still around and works as a mechanism to
build SessionFactory as long as that is all you do.
2) split naming strategy into implicit and explicit contracts.
3) switch from using dom4j to process hbm.xml files to JAXB+StAX

This release I started keeping a working list of changes, ideas, todos, and
things-to-discuss in the repo as working-5.0-migration-guide.md[2].  I will
base the Migration Guide for 5.0 on the top list here, so if you run into
anything that is not covered there and you think should be, let me know.
As for the "TODOs" and "Proposals for discussion" lists, take a look and
let me know if you have any thoughts.


[1] At the moment, this means that the top-level build will not run in its
entirety.  It will break as soon as it gets to Envers.
[2]
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev