]
Scott Marlow commented on WFLY-3619:
------------------------------------
[~aliebscher], I want to help you but would rather answer your question in the wildfly
forums. Is there any reason why you haven't asked yet on the
[
] forum? I understand that you
started asking in the EJB3 forum (I don't think that was the right place to ask your
questions).
I'll close this jira now, since we have not identified any symptons that suggest that
an actual bug needs to be fixed. Please comment again here with the forum link when you
have it.
XA END / un-enlist for database connection called to early
----------------------------------------------------------
Key: WFLY-3619
URL:
https://issues.jboss.org/browse/WFLY-3619
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB, JCA, JPA / Hibernate, Transactions
Affects Versions: 8.0.0.Final
Environment: Windows 7 64-bit
JDK 1.8.0_05-b13 64-Bit
MS SQL Server 2012 database
Latest MS JDBC driver
XA datasource
Reporter: Andreas Liebscher
Assignee: Scott Marlow
Priority: Blocker
Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log,
server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz,
server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log
While trying to port an EE application from JBoss5 to WF8 the following problem
occurred:
EJBs (@Required) using JPA to do some data changes.
Some changes get already written to the database, others reside in the session cache.
After the top EJB call returns, a Hibernate Session flush is triggered in
beforeCompletion.
Then more changes are flushed to the database, but I run in a reproduceable database
locking problem.
After some time an update of a row fails with lock wait timeout. This row has been
inserted prior during the EJB call.
There should be exactly one xa transaction active processing all data changes.
But the database shows two active session, one is an xa transaction with sessionId -2
(orphaned), the other session is a local transaction.
After analyzing all database communication with the help of the JDBC driver logging I
found the following behaviour:
- a connection is enlisted and xa start called
- the same connection is used for several select / insert / update statements
- after return of the top EJB call on the same connection xa end and connection un-enlist
is called
- the same connection is used for session flush (beforeCompletion) but with local
transaction because the connection is no longer associated with the xa transaction, so
locks can be expected.
Shouldn't xa end be called AFTER beforeCompletion / session flush!?!