what does ""DEBUG [org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl] (EJB default - 6) Skipping JTA sync registration due to auto join checking" mean?
5:23 p.m.
I'm trying to help a user [1] that is complaining that a local database
transaction is used, instead of the JTA transaction as they expect. I
asked them to enable TRACE logging for { org.jboss.jca, org.hibernate,
org.jboss.as.jpa + com.arjuna} and see the "Skipping JTA sync
registration due to auto join checking" log message.
What does the "skipping JTA sync registration due to auto join checking"
mean exactly? [2] shows a small example of the log output with an
active JTA transaction in use.
Scott
[1] https://issues.jboss.org/browse/WFLY-3619 XA END / un-enlist for
database connection called to early
[2] http://fpaste.org/125603/80296401/
5:59 p.m.
Well it *should* mean that the EM in question was created outside the scope
of a transaction. The JPA spec says that in cases of an
application-managed PC where the EM is created outside the scope of the JTA
txn, the provider should not automatically join the EM to any JTA txn later
implicitly. Instead the expectation is for the application to explicitly
join the EM to the transaction via the EM.joinTransaction method:
<quote>
When a JTA application-managed entity manager is used, if the entity
manager is created outside the
scope of the current JTA transaction, it is the responsibility of the
application to join the entity manager
to the transaction (if desired) by calling EntityManager.joinTransaction.
If the entity man-
ager is created outside the scope of a JTA transaction, it is not joined to
the transaction unless Entity-
Manager.joinTransaction is called.
</quote>
Note this behavior was made somewhat controllable in JPA 2.1 with the
introduction of SynchronizationType.
I'd have to refresh my memory on the expectation here wrt container-managed
PCs. So that would be my first question to you of the situation... Is this
a app or container managed PC?
It is odd that they see a "local database transaction" instead though. You
sure this isn't a series of auto-commit transactions?
On Thu, Aug 14, 2014 at 10:23 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
I'm trying to help a user [1] that is complaining that a local
database
transaction is used, instead of the JTA transaction as they expect. I
asked them to enable TRACE logging for { org.jboss.jca, org.hibernate,
org.jboss.as.jpa + com.arjuna} and see the "Skipping JTA sync
registration due to auto join checking" log message.
What does the "skipping JTA sync registration due to auto join checking"
mean exactly? [2] shows a small example of the log output with an
active JTA transaction in use.
Scott
[1] https://issues.jboss.org/browse/WFLY-3619 XA END / un-enlist for
database connection called to early
[2] http://fpaste.org/125603/80296401/
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:28 p.m.
On 08/14/2014 11:59 AM, Steve Ebersole wrote:
Well it *should* mean that the EM in question was created outside
the
scope of a transaction. The JPA spec says that in cases of an
application-managed PC where the EM is created outside the scope of the
JTA txn, the provider should not automatically join the EM to any JTA
txn later implicitly. Instead the expectation is for the application to
explicitly join the EM to the transaction via the EM.joinTransaction method:
<quote>
When a JTA application-managed entity manager is used, if the entity
manager is created outside the
scope of the current JTA transaction, it is the responsibility of the
application to join the entity manager
to the transaction (if desired) by calling
EntityManager.joinTransaction. If the entity man-
ager is created outside the scope of a JTA transaction, it is not joined
to the transaction unless Entity-
Manager.joinTransaction is called.
</quote>
Note this behavior was made somewhat controllable in JPA 2.1 with the
introduction of SynchronizationType.
I'd have to refresh my memory on the expectation here wrt
container-managed PCs. So that would be my first question to you of the
situation... Is this a app or container managed PC?
It is odd that they see a "local database transaction" instead though.
You sure this isn't a series of auto-commit transactions?
I won't be sure until they enable TRACE logging for org.jboss.as.jpa and
give us more logs. I'm waiting for that.
On Thu, Aug 14, 2014 at 10:23 AM, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
I'm trying to help a user [1] that is complaining that a local database
transaction is used, instead of the JTA transaction as they expect. I
asked them to enable TRACE logging for { org.jboss.jca, org.hibernate,
org.jboss.as.jpa + com.arjuna} and see the "Skipping JTA sync
registration due to auto join checking" log message.
What does the "skipping JTA sync registration due to auto join checking"
mean exactly? [2] shows a small example of the log output with an
active JTA transaction in use.
Scott
[1] https://issues.jboss.org/browse/WFLY-3619 XA END / un-enlist for
database connection called to early
[2] http://fpaste.org/125603/80296401/
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:32 p.m.
Or you could just ask them ;)
On Thu, Aug 14, 2014 at 11:28 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
On 08/14/2014 11:59 AM, Steve Ebersole wrote:
> Well it *should* mean that the EM in question was created outside the
> scope of a transaction. The JPA spec says that in cases of an
> application-managed PC where the EM is created outside the scope of the
> JTA txn, the provider should not automatically join the EM to any JTA
> txn later implicitly. Instead the expectation is for the application to
> explicitly join the EM to the transaction via the EM.joinTransaction
> method:
>
> <quote>
> When a JTA application-managed entity manager is used, if the entity
> manager is created outside the
> scope of the current JTA transaction, it is the responsibility of the
> application to join the entity manager
> to the transaction (if desired) by calling
> EntityManager.joinTransaction. If the entity man-
> ager is created outside the scope of a JTA transaction, it is not joined
> to the transaction unless Entity-
> Manager.joinTransaction is called.
> </quote>
>
> Note this behavior was made somewhat controllable in JPA 2.1 with the
> introduction of SynchronizationType.
>
> I'd have to refresh my memory on the expectation here wrt
> container-managed PCs. So that would be my first question to you of the
> situation... Is this a app or container managed PC?
>
> It is odd that they see a "local database transaction" instead though.
> You sure this isn't a series of auto-commit transactions?
>
I won't be sure until they enable TRACE logging for org.jboss.as.jpa and
give us more logs. I'm waiting for that.
>
>
>
> On Thu, Aug 14, 2014 at 10:23 AM, Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
> I'm trying to help a user [1] that is complaining that a local
> database
> transaction is used, instead of the JTA transaction as they expect. I
> asked them to enable TRACE logging for { org.jboss.jca, org.hibernate,
> org.jboss.as.jpa + com.arjuna} and see the "Skipping JTA sync
> registration due to auto join checking" log message.
>
> What does the "skipping JTA sync registration due to auto join
> checking"
> mean exactly? [2] shows a small example of the log output with an
> active JTA transaction in use.
>
> Scott
>
>
> [1] https://issues.jboss.org/browse/WFLY-3619 XA END / un-enlist for
> database connection called to early
>
> [2] http://fpaste.org/125603/80296401/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
7:43 p.m.
On 08/14/2014 12:32 PM, Steve Ebersole wrote:
Or you could just ask them ;)
I might not getting enough detail from the answer. Best to have trace
output. Speaking of which,
https://gist.github.com/scottmarlow/b7fe320f5a2ea7969170 shows a
transaction scoped persistence context is created within a JTA transaction.
I don't understand why we see the "Skipping JTA sync registration..."
message and we then see that ORM registered a Sync via
TransactionSynchronizationRegistry.registerInterposedSynchronization(),
which is followed by TransactionCoordinatorImpl logging "successfully
registered Synchronization".
Also (unrelated to the above question), after some IRC discussion about
[3] and why Hibernate registers a Synchronization callback per session
(at the JTA transaction level). I'm wondering if we should consider
having a Hibernate classloader level (TransactionLocal) collection of
hibernate session sync callbacks, so that we only have one Hibernate
Synchronization registered and we could close the database connection
(within the TXN) after running all of the per session syncs. This could
be two passes:
For each Session:
session.beforeCompletion();
For each Session:
session.closeDBConnections();
Thoughts?
Scott
[3] https://community.jboss.org/message/901701
On Thu, Aug 14, 2014 at 11:28 AM, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
On 08/14/2014 11:59 AM, Steve Ebersole wrote:
Well it *should* mean that the EM in question was created
outside the
scope of a transaction. The JPA spec says that in cases of an
application-managed PC where the EM is created outside the scope
of the
JTA txn, the provider should not automatically join the EM to
any JTA
txn later implicitly. Instead the expectation is for the
application to
explicitly join the EM to the transaction via the
EM.joinTransaction method:
<quote>
When a JTA application-managed entity manager is used, if the entity
manager is created outside the
scope of the current JTA transaction, it is the responsibility
of the
application to join the entity manager
to the transaction (if desired) by calling
EntityManager.joinTransaction. If the entity man-
ager is created outside the scope of a JTA transaction, it is
not joined
to the transaction unless Entity-
Manager.joinTransaction is called.
</quote>
Note this behavior was made somewhat controllable in JPA 2.1
with the
introduction of SynchronizationType.
I'd have to refresh my memory on the expectation here wrt
container-managed PCs. So that would be my first question to
you of the
situation... Is this a app or container managed PC?
It is odd that they see a "local database transaction" instead
though.
You sure this isn't a series of auto-commit transactions?
I won't be sure until they enable TRACE logging for org.jboss.as.jpa
and give us more logs. I'm waiting for that.
On Thu, Aug 14, 2014 at 10:23 AM, Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>
<mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote:
I'm trying to help a user [1] that is complaining that a
local database
transaction is used, instead of the JTA transaction as they
expect. I
asked them to enable TRACE logging for { org.jboss.jca,
org.hibernate,
org.jboss.as.jpa + com.arjuna} and see the "Skipping JTA sync
registration due to auto join checking" log message.
What does the "skipping JTA sync registration due to auto
join checking"
mean exactly? [2] shows a small example of the log output
with an
active JTA transaction in use.
Scott
[1] https://issues.jboss.org/__browse/WFLY-3619
<https://issues.jboss.org/browse/WFLY-3619> XA END / un-enlist for
database connection called to early
[2] http://fpaste.org/125603/__80296401/
<http://fpaste.org/125603/80296401/>
_________________________________________________
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>
3529
days inactive
3537
days old
4 comments
2 participants
participants (2)
-
Scott Marlow -
Steve Ebersole