I think this question would be best answered by our JPA experts over on the WildFly forum. It sounds like the connection you are obtaining via JDBC is different to the one that the EM is using which is logical. I don't believe the JCA implementation uses a thread local to track the same connection being retrieved multiple times.
I don't think it is related to the synchronization issue. It is more likely to do with the database possibly returning isSameRM false to the second connection so a new branch is being used which would lock one another out.
Do you actually need to intermingle JDBC with JPA in your app or where you just testing something? Either way the discussion is best on the WildFly forum, but please do add a link here to where the discussion moves to so I can follow it too.
Are you using WildFly 8.1 with an updated IronJacamar jar or perhaps using a WildFly 8.2 pre-release build? I'm trying to understand if your possibly seeing the problem where the resource is delisted before work is done.
can you explain the meaning of <isSameRM-override-value>false</isSameRM-override-value> in XA datasource definitions?
I cannot find any documentation on that besides the sentence "The is-same-rm-override element allows one to unconditionally set whether the javax.transaction.xa.XAResource.isSameRM(XAResource) returns true or false.".
Any JB 5.1 XA datasource examples and also the current IronJacamar user guide contains <isSameRM-override-value>false</isSameRM-override-value> in any XA datasource definition example.
We tried to set it to TRUE resulting in throwing TransactionRequiredExceptions all the time.
My apologies, I was not really fully clear. My research into an unrelated issue earlier this year actually found that most databases do not support TMJOIN correctly anyway so isSameRM is a bit of a red herring.
The way the config works is:
<isSameRM-override-value>false</isSameRM-override-value> - this will make isSameRM return false and new branches be created
<isSameRM-override-value>true</isSameRM-override-value> - this will make isSameRM return true and so TMJOIN will always be used
No <isSameRM-override-value> setting at all means use the driver implementation
/cc jesper.pedersen to confirm.
I think the default is to define a DS with isSameRM = false. This works in most cases but has the impact that you can deadlock yourself if you have two connections to the same resources in the same transaction. Which is quite possibly what you are seeing.
Here the link to the WF forum: WildFly 8.1.0.Final + MSSQL XA DataSource cannot handle JPA and JDBC in parallel
I think it's one connection to the same resource in the same transaction but with different branches / xid.
So why is datasource.getConnection() associating a new branch / xid?
I guess <isSameRM-override-value>true</isSameRM-override-value> would prevent that behaviour but makes a lot of other problems. Is TMJOIN really not implemented correctly in the MS JDBC Driver for MSSQL?
Has anyone successfully managed to run MSSQL with <isSameRM-override-value>true</isSameRM-override-value>?
The default for <is-same-rm-override> is returning the drivers isSameRM() value. Setting the element to false/true will always return the value defined.
https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html/Administration_and_Configur… has a definition of false, but you should verify with the help of TRACE of org.jboss.jca and com.arjuna.