[jboss-as7-dev] JTA Synchronization.afterCompletion callback can occur in a background thread but JPA EntityManager must be accessed in single-threaded manner...

[David M. Lloyd]

To be perfectly honest, I don't think the TM is the best place to be 
tracking timeouts - the front end should always do stuff like that when 
possible (imo).  But that ship has sailed, as they say; I think this 
proposal sounds workable, if a bit tedious to implement.

On 02/22/2013 02:11 PM, Steve Ebersole wrote:
> Thats sort of what we are planning on doing.  The rub is every library
> that interacts with JTA having to do this as well.  Thats more what I
> think Scott was getting at.
>
> For clarity your suggestion (method entry checks) is part of our
> solution.  We will also do method exit checks.  Ugh.  Lot of work to
> handle something the TM is doing
>
> On Feb 22, 2013 1:53 PM, "Jason Greene" <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>     I had a discussion with Steve about this. Not sure if you guys
>     talked about my suggestion.
>
>     My suggestion was to simply detect if afterCompletion is running on
>     the thread that created it. If the threads match proceed normally.
>     If, however, they do not match then DO NOTHING (well at first):)
>
>     Then have the EntityManager, immediately before certain actions such
>     as a flush, detect if the Transaction has been rolled back (using
>     Transaction.getStatus()). If it has been rolled back then at that
>     point of time trigger an exception to the calling application code,
>     with a message that the "Transaction manager has decided to revert
>     the transaction, either due to a timeout or a resource failure.
>     Check your log for details".
>
>     On Feb 22, 2013, at 8:45 AM, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>      > Related jira issues are HHH-7910 + AS7-6586.  HHH-7910 has been
>     around a
>      > bit longer and contains comments about the current plan to
>     address the
>      > issue in Hibernate.
>      >
>      > As mentioned in HHH-7910, the JTA specification allows
>      > Sychronization.afterCompletion callbacks to occur in a different
>     thread
>      > than the application thread that is using the transaction
>     (typically for
>      > transaction timeout or when a transaction is propagated to a
>     remote thread).
>      >
>      > Since the JPA EntityManager is by design, not thread safe,
>     invoking the
>      > EntityManager.clear() or EntityManager.close() methods from a
>     background
>      > thread while the application thread may be in the middle of an
>      > EntityManager invocation is not the best situation (IMO).
>      >
>      > One improvement that we talked to the JBossTM/TS team about, is
>     adding a
>      > TM policy that arranges for the Synchronization.afterCompletion to
>      > always run in the application thread (some of the IRC discussion is
>      > attached to HHH-7910).  The TM team doesn't think that they could do
>      > that for both the TX timeout and tx propagating to a remote thread
>      > (JBossTS) uses.
>      >
>      > One alternative solution, might be to create a top level
>     container level
>      > queue that the background thread Synchronization.afterCompletion
>     defers
>      > processing to.  As soon as the application thread returns control
>     to the
>      > top level, the queue is processed in FIFO order.
>      >
>      > *Does AS have any other uses of Synchronization.afterCompletion or
>      > Synchronization.beforeCompletion that expect to run in the
>     application
>      > thread*?
>      >
>      > From the JPA specification about thread unsafety:
>      >
>      > "
>      > An entity manager must not be shared among multiple concurrently
>      > executing threads, as the entity manager and persistence context
>     are not
>      > required to be threadsafe. Entity managers must only be accessed in a
>      > single-threaded manner.
>      > "
>      > _______________________________________________
>      > jboss-as7-dev mailing list
>      > jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     --
>     Jason T. Greene
>     JBoss AS Lead / EAP Platform Architect
>     JBoss, a division of Red Hat
>
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
- DML