WildFly 8.1.0.Final + MSSQL XA DataSource cannot handle JPA and JDBC in parallel

[aliebscher]

When using an EJB with REQUIRED transaction attribute and MSSQL XA DataSource we often get Lock Timeouts.

We have loaded an JPA entity, in the corresponding table one attribute is updated with JDBC (DataSource.getConnection()) to prevent increment of the VERSION field.

After that when trying to update the JPA entity with em.refresh() lock timeouts occur.

This indicates that the database connection the EM uses (of course it is the same xa datasource) and the connection we receive directly from the datasource for JDBC update are NOT correctly associated with the same XA transaction!

Similar behaviour to the association problem in beforeCompletion: Re: Re: new requirement for synchronization ordering (WildFly is delisting resources during Sychronization.beforeComplet…

Transactions forum: Re: WildFly 8.1 + MSSQL XA DataSource cannot handle JPA and JDBC in parallel

[smarlow]

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. 

[aliebscher]

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.

Andreas

[tomjenkinson]

Hi Andreas,

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.

Thanks,

Tom

[dsimko]

Hi,

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?

Thanks,

Dan