[
https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin...
]
Scott Marlow commented on JBJCA-1357:
-------------------------------------
[
https://developer.jboss.org/message/920148#920148] seems related, you could read the
entire forum thread if you like. We solved this only in the WildFly application server
(as well as the Red Hat EAP product), by adding special ordering code that always executes
the IJ interposed synchronization class last.
So, with this synchronization ordering solution that is implemented directly in the
WildFly code, during beforeCompletion, the IJ sync runs after other interposed syncs.
During afterCompletion, the IJ sync runs after other interposed syncs.
Since your test case shows that your not running in WildFly, of course, you still see the
problem that we solved only for WildFly. Are you using WildFly (or EAP) to run the
software where you actually hit JBJCA-1357?
TransactionSynchronizer registered as interposed synchronization
leads to ordering issue when using hibernate
-------------------------------------------------------------------------------------------------------------
Key: JBJCA-1357
URL:
https://issues.jboss.org/browse/JBJCA-1357
Project: IronJacamar
Issue Type: Bug
Affects Versions: 1.4.5
Reporter: Alexander Pinske
Attachments: jca-hibernate.zip
The TransactionSynchronizer (to cleanup connections) is registered as an interposed
synchronization. Hibernate also registers its synchronization (to close the underlying
JDBC connection handle) as interposed.
This leads to undefined ordering, which in my case runs the JCA Synch before the
Hibernate Synch. This leads to a log of IJ000316 and the connection being killed.
I think that platform specific cleanup should be executed after all application level
synchronization have run, therefore it should be registered with the TM (not the TSR).
http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application
misbehaviour. But I don't think the application has any means of controlling the
ordering in this scenario.
If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the
registration of the TransactionSynchronizer via TransactionManager - thus non-interposed)
has the problem that AbstractPool uses the TSR to check if a transaction is actually in
progress.
I don't know if my rationale is correct. Could you please comment on the issue?
Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)