[jboss-jira] [JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate

[Alexander Pinske (JIRA)]

    [ https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482503#comment-13482503 ] 

Alexander Pinske commented on JBJCA-1357:
-----------------------------------------

Thank you for the quick answer and the helpful pointers! I understand the workaround in wildfly.

We are currently looking into using JCA&JTA outside of an application server. My understanding was that the "new" TSR method (interposed synch) was for integrating other components (e.g. JPA), whereas the method on Transaction ("normal" synch) was for platform components (e.g. JCA).

Why is the JCA implementation not using Transaction.registerSynch? Wouldn't that solve the problem? Ironjacamar has the fallback to this method already anyways, when a TSR is not present. To which components are the non-interposed synchronisations targeted?

Appreciate your answers. Thanks for your time on this!


> 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)