[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3619:
------------------------------------
I asked about the "Skipping JTA sync registration due to auto join checking on [http://lists.jboss.org/pipermail/hibernate-dev/2014-August/011650.html]. I'm not yet sure if that is wrong or not yet.
> 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: server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.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)
11 years, 8 months
[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3619:
------------------------------------
I'm not sure why we are seeing this message:
{quote}
2014-08-14 09:24:19,357 DEBUG [org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl] (EJB default - 6) Skipping JTA sync registration due to auto join checking
{quote}
Also, org.jboss.jpa should be org.jboss.as.jpa
> 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: server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.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)
11 years, 8 months
[JBoss JIRA] (WFLY-1513) remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1513?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1513:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1127586
> remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-1513
> URL: https://issues.jboss.org/browse/WFLY-1513
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JMS
> Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2
> Reporter: jaikiran pai
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> The remove (management) operation on a JMS queue merely unbinds the queue from JNDI instead of destroying the queue. It appears that the change was done as part of https://issues.jboss.org/browse/AS7-1899 (the PR is here https://github.com/wildfly/wildfly/pull/398). The change done in that PR to address the original issue reported in that other JIRA doesn't look right.
> So the original issue reported in that thread is that a server has a queue with messages and the server is stopped. Upon restart the messages have disappeared because upon stop, the JMSQueueService's stop() method used to destroy the queue. The real fix would have been to differentiate the "remove()" operation from a mere service stop. The explicit remove (handler) would then be responsible for destroying the queue (which even means a JNDI unbind) and not that service's stop method.
> All of this even applies to the JMS topic which has a similar problem.
> On a related note, the add() operation too seems suspicious because it ends up calling a createXXX on the JMSServer API which says:
> {code}
> /**
> * Creates a JMS Queue.
> *
> * @param queueName
> * The name of the queue to create
> * @param selectorString
> * @param durable
> * @return true if the queue is created or if it existed and was added to
> * JNDI
> * @throws Exception
> * if problems were encountered creating the queue.
> */
> boolean createQueue(boolean storeConfig, String queueName, String selectorString, boolean durable, String ...bindings) throws Exception;
> {code}
> Notice the "if the queue is created or if it existed and was added to JNDI" part. So it appears that the management "add" operation can end up behaving like an update (write-attribute) kind of operation in some cases. I'm not sure if that's good thing.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-297:
-----------------------------------------
Does this need to be an extra profile?
Can't the enforcer rule be smart enough to do the following "if the version of this module is not a SNAPSHOT, then it should have no SNAPSHOT dependencies"?
> The release procedure should validate there are no snapshot dependencies with the enforcer plugin
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-297
> URL: https://issues.jboss.org/browse/DROOLS-297
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me.
> Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this:
> http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html
> During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc.
> But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best.
> One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend):
> https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700
> But I strongly dislike the use of profiles...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months