[jboss-jira] [JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early

Scott Marlow (JIRA) issues at jboss.org
Wed Aug 20 10:47:30 EDT 2014


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

Scott Marlow commented on WFLY-3619:
------------------------------------

Lets continue the discussion on [https://community.jboss.org/en/wildfly?view=discussions] about whether there is a bug or not with un-enlist being called too early.  We can reference this jira from there.  The reason for relocating the discussion of this potential bug, is to allow others to also participate in the discussion (especially developers that write the code that does the un-enlist).  If there is actually a bug in the application server, we can reopen this jira.  

Agreed?



> 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!?!



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


More information about the jboss-jira mailing list