Does this recreate after you workaround the XAResource delist problem that we previously discussed? By workaround, I mean building from the latest WildFly or using a more recent IronJacamar.
Still using 8.1.0.Final.
This is completely another situation.
The problem with beforeCompletion occurred during em.flush() within beforeCompletion(). A workaround was to call em.flush() at the end of job execution before transaction commit is handled.
But now we have a similar problem that has nothing to do with commit phase but with intermixing JPA and JDBC within one xa transaction.
I guess there are different branches involved leading to this lock.
I chatted with Jesper about this on #jca. In theory it turns out that JCA should be returning the same connection for JPA and your JDBC so I think we need to see your trace log here please.
I have added described scenario to our testsuite and I can confirm that DataSource.getConnection() returns the exactly same connection like the one which is already associated (enlisted) with Transaction (due to loading entity by entityManager). Tested with WF 8.1.0.Final and 10.0.0.Final. So in my opinion the mentioned "Lock Timeouts" is caused by concurrent EJBs call.
Andreas, could you please provide more details?