On Feb 22, 2013, at 8:45 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
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.
This would be equivalent to trying to commit the transaction or trying to write to a
database thats already been informed the TX was reverted.
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.
Well the problem is TX boundaries typically are the lifespan of the request, so the
application thread would never fully give up control. The only thing you can really
without relying on checks, or deferring to the db/tm, is to interrupt the application
thread from the sync thread. However the EntityManager would have to be carefully coded to
process thread interruption in a way that distinguishes between tx timeout and user
requested interrupt. It's probably the same amount of code either way.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat