12:42 p.m.
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 <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> 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
<https://github.com/jbosstm/jboss-transaction-spi/pull/5>
[5] https://github.com/jbosstm/__narayana/pull/810
<https://github.com/jbosstm/narayana/pull/810>
On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>
<mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> 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
<https://developer.jboss.org/thread/252572?start=45&tstart=0>
[2]
https://github.com/mmusgrov/__jboss-transaction-spi/blob/__threadDisassoc...
<https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociati...
[3]
https://github.com/__scottmarlow/wildfly/tree/__transactiontimeout_client...
<https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_n...
_________________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
<mailto:hibernate-dev@lists.__jboss.org
<mailto:hibernate-dev@lists.jboss.org>>
https://lists.jboss.org/__mailman/listinfo/hibernate-dev
<https://lists.jboss.org/mailman/listinfo/hibernate-dev>