1 2 Previous Next 29 Replies Latest reply on Feb 12, 2014 12:02 PM by tomjenkinson

    XAER_DUPID: The XID already exists (even with new mysql connector)

    nbarrera

      Hi all,

       

      I 've the following scenario:

       

      1 wildfly server with 3 webapps, and a mysql server engine with two databases (name of databases is jta1 and jta2). Both wildlfy and mysql engine are installed in the same box.

       

      webapp#1 contains a web service that connects and inserts on database jta1.

      webapp#2 contains a web service that connects and inserts on database jta2.

      webapp#3 is a servlet wich acts as a ws-at client opening a ws-at transaction and finally commiting or rollbacking the transaction.

       

      Problem araises after the client call to the second web service, the exception thrown is as follows:

       

      11:07:47,509 INFO  [stdout] (default task-7) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>   SERVICE B
      11:07:47,566 WARN  [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (default task-7) IJ000305: Connection error occured: org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@cb9a4e[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@ff774a connection handles=0 lastUse=1390831667508 trackByTx=true pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@4e0e9 mcp=SemaphoreArrayListManagedConnectionPool@1d400b[pool=jta2] xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@ff774a txSync=null]: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
          at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:601) [mysql-connector-java-5.1.28.jar:]
          at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:584) [mysql-connector-java-5.1.28.jar:]
          at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:524) [mysql-connector-java-5.1.28.jar:]
          at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
          at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:637)
          at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:398)
          at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:843)
          at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:344)
          at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:523)
          at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:768)
          at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:516)
          at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
          at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:81) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.prepare(IdentityGenerator.java:69) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:30) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2163) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2643) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:51) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:298) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.springframework.orm.hibernate3.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:686) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:1) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate.save(HibernateTemplate.java:683) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at ar.com.condortech.test.jboss.jbbiz.managers.ServiceBManager.createRecord(ServiceBManager.java:23) [jbbiz-0.0.1-SNAPSHOT.jar:]
          at ar.com.condortech.test.jboss.jbweb.webservices.impl.ServiceBImpl.doSomethingB(ServiceBImpl.java:34) [classes:]
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
          at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
          at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
          at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
          at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
          at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
          at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
          at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.mandatory(CMTTxInterceptor.java:302) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:233) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
          at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
          at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
          at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
          at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:112)
          at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149)
          at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
          at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178)
          at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
          at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129)
          at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
          at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
          at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
          at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
          at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
          at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239)
          at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:92)
          at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:143)
          at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
          at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final]
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
          at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
          at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
      
      11:07:47,602 WARN  [com.arjuna.ats.jta] (default task-7) ARJUNA016061: TransactionImple.enlistResource - XAResource.start returned: ARJUNA016099: Unknown error code:0 for < 131080, 29, 64, 0000000000-1-1127011-81-5413-7682-2610223000-11849, 292929292929292929292828156293030-52-2542-47111313152292929-89782929292929292929292929292929292929292929292929292929292929292929292929 >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: No operations allowed after connection closed.
          at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:605) [mysql-connector-java-5.1.28.jar:]
          at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:584) [mysql-connector-java-5.1.28.jar:]
          at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:524) [mysql-connector-java-5.1.28.jar:]
          at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
          at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:637)
          at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:398)
          at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:843)
          at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:344)
          at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:523)
          at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:768)
          at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:516)
          at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
          at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:81) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.prepare(IdentityGenerator.java:69) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:30) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2163) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2643) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:51) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:298) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519) [hibernate-3.2.6.ga.jar:3.2.6.ga]
          at org.springframework.orm.hibernate3.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:686) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:1) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at org.springframework.orm.hibernate3.HibernateTemplate.save(HibernateTemplate.java:683) [spring-orm-3.1.0.RELEASE.jar:3.1.0.RELEASE]
          at ar.com.condortech.test.jboss.jbbiz.managers.ServiceBManager.createRecord(ServiceBManager.java:23) [jbbiz-0.0.1-SNAPSHOT.jar:]
          at ar.com.condortech.test.jboss.jbweb.webservices.impl.ServiceBImpl.doSomethingB(ServiceBImpl.java:34) [classes:]
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
          at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
          at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
          at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
          at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
          at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
          at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
          at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.mandatory(CMTTxInterceptor.java:302) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:233) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
          at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
          at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
          at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
          at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:112)
          at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149)
          at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
          at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178)
          at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
          at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129)
          at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
          at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
          at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
          at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
          at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
          at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239)
          at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:92)
          at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:143)
          at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
          at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final]
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
          at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
          at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
      

       

      By looking in this forum I 've found the following post which reports a very similar (or the same) exception but a slightly different scenario. That scenario uses more than one jboss instance while I 'm using just a single jboss instance. It mentions the jboss node name property but finally points out a mysql connector bug.

       

      Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists

       

      This post is related with this JBTM JIRA Issue: [JBTM-1336] DUPID detection for mysql in JTS mode does not work - JBoss Issue Tracker

      The issue is linked with the MYSQL issue: http://bugs.mysql.com/bug.php?id=69506

      The MYSQL issue is closed as of version 5.1.27, Tom reported the  issue providing a TestCase which I could run with the mysql connector I 'm using and the test passed succesfully so perhaps you could close the JBTM-1336 issue.

      I 'm using mysql connector 5.1.28 (the latest available) in my scenario.

       

      I hope you could give me a hand by perhaps pointing out a new bug on the mysql connector or detecting an error in my scenario,

      it seems that for the reported case the new mysql connector is working fine (returning -8 DUPID instead of sql error code 0) but for the scenario I 'm trying to set up it's still returning 0.

       

      I 've also tested changing my scenario to use two different instances of the mysql engine (i.e. in two different boxes) and the error is gone, but I 'd rather use a single mysql engine as I first tested.

       

       

      thank you in advance,

       

      Nicolas

        • 1. Re: XAER_DUPID: The XID already exists (even with new mysql connector)
          nbarrera

          Hi all,

          continuing my research to solve this I 've gathered more information from a wireshark capture where I was trying to monitor the interactions between my applications and the mysql engine.

           

          I 'm attaching the .cap file in the following link

          http://www.mediafire.com/download/8gmzwqm5t95u859/failXa.cap

           

          You can filter it with wireshark using mysql as the filter.

           

          what I see is two interactions (looking at the tcp sequence numbers)

           

          1st interaction (should be the first service) does:

           

          XA start (with an xid ending with 2008)

          insert into

           

          Then the 2nd Interaction (should be the second service)

           

          first of all it receives some strange (to me) messages from the mysql server like greeting, then it asks for login request (this is strange as the first interaction never does this sorry perhaps this is near to OFFTOPIC as perhaps it's to close to mysql but it's what I 'm seeing here)

          then it seems to ask for variable statuses asks for tx_isolation

          sets auto commit to true and performs

          XA start (with xid ending with 2005)

          XA commit ONE PHASE (but no inserts are done in between start and commit)

          XA start (with xid ending with 2008... again!)

             here mysql response is a 1440 XER_DUPID

           

          At last the first service (with the 1st interaction sequence numbers plays it's part again) with

          XA end (2008)

          XA rollback (2008)

           

           

          I will post here the client code and the services' code (in fact services are kind of copied just because the hole thing is a POC by now and once proven this works it will be implemented with services we already got developed)

           

          Before you read the code I 'd like to present some doubts,

           

          a) Do you have any idea of what could be that strange transaction that's opened against mysql (the one ending with 2005)?

          b) What's supposed to happen if the exception carried a -8 errorCode instead of 0? XTS code would retry to start the XA transaction with a different id?

           

          thank you in advance, hope this snippets help to describe my problem.

          Nicolas.-

           

          Client code (taken from BasicClient.java from the xts-demo project):

           

              public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
              {
                  System.out.println("CLIENT: obtaining userTransaction...");
                  UserTransaction ut = null;
          
                  Context initialContext;
                  try {
          
                      initialContext = new InitialContext();
                      ut = (UserTransaction)initialContext.lookup("java:comp/UserTransaction");
          
                  } catch (NamingException e2) {
                      // TODO Auto-generated catch block
                      e2.printStackTrace();
                  }
          
          
                  try {
          
                      System.out.println("CLIENT: starting the transaction...");
          
                      ut.begin();
          
                      System.out.println("CLIENT: transaction ID= " + ut.toString());
          
                      System.out.println("CLIENT: calling business Web Services...");
          
          
                      URL wsdlLocation1 = new URL("http://localhost:8080/jbweb_1/ServiceA/ServiceAImpl?wsdl");
                      QName serviceName1 = new QName("http://condor-users.com/serviceA", "ServiceA");
                      QName portName1 = new QName("http://condor-users.com/serviceA", "ServiceAService");
          
                      Service service1 = Service.create(wsdlLocation1, serviceName1);
                      IServiceA client1 = service1.getPort(portName1, IServiceA.class);
          
                      // Llamando al service A
                      client1.doSomethingA();
          
          
                      URL wsdlLocation2 = new URL("http://localhost:8080/jbweb_2/ServiceB/ServiceBImpl?wsdl");
                      QName serviceName2 = new QName("http://condor-users.com/serviceB", "ServiceB");
                      QName portName2 = new QName("http://condor-users.com/serviceB", "ServiceBService");
          
                      Service service2 = Service.create(wsdlLocation2, serviceName2);
                      IServiceB client2 = service2.getPort(portName2, IServiceB.class);
          
                      // Llmanado al service B
                      client2.doSomethingB();
          
                      System.out.println("CLIENT: calling commit on the transaction...");
          
                      ut.commit();
          
                      System.out.println("done.");
                      System.out.flush();
          
                  } catch (Exception e) {
                      System.out.println("eerrrror");
                      e.printStackTrace();
                      if (ut != null) {
                          try {
          
                              /// ROLLBACK
                              ut.rollback();
          
                          } catch (Exception e1) {
                              e1.printStackTrace();
                          }
                      }
                  }
          
              }
          

           

           

           

          ServiceA (first service):

          @WebService(serviceName = "ServiceA", 
              portName="ServiceAService", 
              targetNamespace="http://condor-users.com/serviceA")
          @SOAPBinding(style = SOAPBinding.Style.RPC)
          //ejb
          @TransactionAttribute(TransactionAttributeType.MANDATORY)
          @Remote(IServiceA.class)
          @Stateless
          @Interceptors(SpringBeanAutowiringInterceptor.class)
          public class ServiceAImpl implements IServiceA {
          
              @Autowired
              private ServiceAManager aManager;
              
              @Override
              @WebMethod
              public void doSomethingA() throws Exception {
                  System.out.println(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>   SERVICE A");
                  
                  aManager.createRecord();
              }
          
          }
          

           

          SerivceA's manager:

           

          @Repository("serviceAManager")
          public class ServiceAManager extends HibernateDaoSupport {
          
              @Autowired
              public void init(SessionFactory factory) {
                  setSessionFactory(factory);
              }
          
              public void createRecord() {
                  this.getHibernateTemplate().save(new Entidad("hola "+new Date()));
              }
          
          }
          

           

           

           

          ServiceB (second service)

          @WebService(serviceName = "ServiceB", 
              portName="ServiceBService", 
              targetNamespace="http://condor-users.com/serviceB")
          
          @TransactionAttribute(TransactionAttributeType.MANDATORY)
          @Remote(IServiceB.class)
          @Stateless
          @Interceptors(SpringBeanAutowiringInterceptor.class)
          public class ServiceBImpl implements IServiceB {
          
              @Autowired
              private ServiceBManager bManager;
          
              @WebMethod
              public void doSomethingB() throws Exception {
                  System.out.println(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>   SERVICE B");
          
                  bManager.createRecord();
              }
          
          }
          

           

           

          ServiceB's manager code:

           

          @Repository("serviceBManager")
          public class ServiceBManager extends HibernateDaoSupport {
          
              @Autowired
              public void init(SessionFactory factory) {
                  setSessionFactory(factory);
              }    
          
              public void createRecord() {
                  this.getHibernateTemplate().save(new Entidad("chau "+new Date()));
              }
          
          }
          

           

           

          As you can see I 'm using an integratino between the jax-ws services (ejbs) and spring based services (called managers here) which are configured to use the jta transaction manager.

          • 2. Re: XAER_DUPID: The XID already exists (even with new mysql connector)
            nbarrera

            Hi again,

             

            I 've continued my tests, now I 've been debugging the mysql-java-connector version 5.1.28 (latest)

             

            I 've settled a breakpoint  

             

            at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:524) [mysql-connector-java-5.1.28.jar:]

             

             

            That's the code executed whenever a sqlexception is received from mysql server and needs to be mapped to the XA error codes.

             

             

            Well, the first time it stops there (first error encountered) is when executing the following sql command:

             

               XA START 0x00000000000000000000ffff7f00010191f4f6c852e6b6cd0000020131,0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,0x20008

             

            that should be the second time an xa transaction is tried to be started with that same xid (previously the first service has tried successfully).

            At this point the exception thrown by the mysql driver is java.sql.SQLException: XAER_DUPID: The XID already exists

            with error code = -8  so I believe that the mysql reported issue http://bugs.mysql.com/bug.php?id=69506 is correctly fixed.

             

            Now there are problems one step ahead.

             

            If I resume the debugging session it then stops a second time on the same breakpoint.

             

            It's now trying to execute the following command:

             

               XA START 0x00000000000000000000ffff7f00010191f4f6c852e6b6cd0000020131,0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,0x20008

             

            It seems to be exactly the same command, but this time the mysql driver throws a MySQLNonTransientConnectionException with message "No operations allowed after connection closed." and SQLState 08003.

             

             

            In a previous post I ask what's XTS supposed to do when it encounters the first exception, now I see it's retrying but is it correct to retry with the same XID?

             

            Anyway, retrying with the same id or a different would yield the same result as I believe that connection has been closed. Do you think the same? Would that be an XTS issue or again a Mysql driver issue what do you think?

             

            thanks again.

            • 3. Re: XAER_DUPID: The XID already exists (even with new mysql connector)
              tomjenkinson

              Hi Nicolas,

               

              I have asked our XTS team to look into this. Generally you might be interested in tracing:

              https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L405

               

              In particular:

              https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L637

               

              And: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L582

              (I am guessing branch is false)

               

              Its a bit like start has been called twice for the same RM. In which case I think it should be an issue in the isSameRM implementation where it is returning false and they are probably the same.

               

              Alternatively, it may be a quirk of XTS and the way it is interposing coordinators.

               

              Tom

              • 4. Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                paul.robinson

                Nicolas,

                 

                Just to be clear, is this your setup?

                 

                forum-diamond.png

                Where webapp#3 begins a WS-AT transaction and then invokes both webapp#1 and webapp#2. #1 and #2 both make updates to the same physical DB?  If this is the case, i suspect we have a diamond issue, coming from the way the WS-AT and JTA transactions are bridged between #3->#1 and #3->#2.

                 

                This is just my initial thought, we will do more investigations.

                 

                Paul.

                • 5. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                  nbarrera

                  Hi Paul,

                   

                  The setup you 've designed is correct.

                   

                  Just to add some detail I would add the following (perhaps you 've already understood this but anyway I 'll mention it):

                   

                  Services #1 and #2 updates different databases which are held inside the same RDBMS instance so (excuse my lack of art skills) I would add a couple of boxes to the design just to highlight this.

                   

                  forum-diamond.png

                   

                  I really don't know if this would  still be a diamond-like trouble with my modifications to the design.

                   

                   

                  I 've intentionally named it "Mysql RDBMS" as I know that it has some limitations on it's XA implementation like this one I 'd like to point out:

                   

                  from

                  http://dev.mysql.com/doc/refman/5.0/en/xa-restrictions.html

                  The requirement that the bqual part of the xid value be different for each XA transaction within a global transaction is a limitation of the current MySQL XA implementation. It is not part of the XA specification.

                  Unfortunately I can't just decide to use another rdbms like postgre because of company restrictions.

                   

                   

                  I 've been debugging TransactionImple (the base one, the subordinate and the jca one) I will comment on this after following all links Tom has suggested but the bottom line is that (after modifying ironjacamar-jdbc) I could get the retry mechanism to work but it's just retrying 20 times the same XID, even with the branch parameter with TRUE value the createXid implementation on subordinate.TransactionImple:

                   

                      @Override  
                    protected Xid createXid(boolean branch, XAModifier theModifier, XAResource xaResource) throws IOException, ObjectStoreException     {       
                        Xid xid = baseXid();    
                     
                        // We can have subordinate XIDs that can be editted       
                        if (xid.getFormatId() != XATxConverter.FORMAT_ID)   
                           return xid;       /// <------    xXXXXXx
                  
                        Integer eisName = null;
                        if(branch) {
                            if(_xaResourceRecordWrappingPlugin != null) { 
                                 eisName = _xaResourceRecordWrappingPlugin.getEISName(xaResource);  
                            }       
                        }
                        ...
                  

                   

                  This method keeps always returning in the line I 've marked with xXXXXXx so it nevers checks for the branch variable value.

                   

                  well I 'll now read Tom's suggestions and after that i 'll comment on which classes I had to modify to reach to this point and I also have a couple of tests yet to run.

                   

                  thanks!

                  • 6. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                    paul.robinson

                    Nicolas,

                     

                    Thanks for the update. I think your deployment still falls under the diamond issue. I don't have time to look into the details of your query at the moment. However, I have asked Gytis to take a look. He is also on the Web service transactions team, so he is well-placed to assist you.

                     

                    If you have time, you could try using two different, physical databases, just to test out this theory. This would make things easier to track down. Alternatively, I think Gytis should be able to reproduce by modifying the Quickstart in [1] to use a single MySQL instance. It would probably be best to use the same version as you do. Maybe you could take a look at that QS to confirm that it matches your problem closely enough?

                     

                    Which version of JBoss/WildFly are you using?

                     

                    Paul.

                     

                    [1] https://github.com/jbosstm/quickstart/tree/master/XTS/wsat-jta-multi_service

                    • 7. Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                      gytis

                      Hi Nicolas,

                       

                      just wanted to let you know, that I am investigating your issue this afternoon. I will let you know as soon as will find anything.

                       

                      Gytis.

                      • 8. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                        nbarrera

                        Thanks Paul and Gytis,

                         

                        Here I provide the information you requested

                         

                        If you have time, you could try using two different, physical databases, just to test out this theory. This would make things easier to track down. Alternatively, I think Gytis should be able to reproduce by modifying the Quickstart in [1] to use a single MySQL instance.

                         

                        I 've tested my scenario changing the Service's #2 datasource to point to another mysql rdbms instance running in another box and that's working fine.

                         

                        Which version of JBoss/WildFly are you using?

                         

                        Wildfly 8.0.0 CR1, it was the latest a couple of days ago.

                         

                         

                        Maybe you could take a look at that QS to confirm that it matches your problem closely enough?

                        I 've looked at that quickstart, in fact I 've started this quest because I 've seen that quickstart seemed quite similar to what I needed. From looking at the Quickstart source code I can't see if the QS uses two different rdbms instances ( I thought it was using the a single h2 rdbms ). So then I thought that the problem was mysql and it's limitations.

                         

                         

                        Now some doubts I 've come across:

                         

                        1) I think I 've found a bug in the toString method of com.arjuna.ats.internal.jta.xa.XID.java (inside wildlfy that class is in the narayana-jta-jacorb.jar I guess) the problem is when trying to printout a XID which format id's is not equals to XATxConverter.FORMAT_ID

                        there is this code (trying to print the branch qualifier)

                                for (int i = 0; i < bqual_length; i++) {
                                    stringBuilder.append(gtrid_length+data[i]);     //// I guess this should be ------> stringBuilder.append(data[ gtrid_length + i ]);
                                }

                        shall I fill a JIRA on the JBTM project?

                         

                         

                        2) I 'd like to ask what the format id is meant for? Sorry I haven't read to much of the xa spec, but what I 'm seeing is that I 'm having two different kind of XIDs being used on XA starts:

                         

                        < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000101:1ae4e79b:52e7efa0:69d, node_name=1, branch_uid=0:ffff7f000101:1ae4e79b:52e7efa0:6a0, subordinatenodename=null, eis_name=unknown eis name >

                         

                        < 131080, 29, 64, 0000000000-1-112701126-28-25-10182-25-17-96006-9249, 2929292929292929292928281562930305514-72111412-67292935-63782929292929292929292929292929292929292929292929292929292929292929292929 >

                         

                        The first one is from format 131077 and the second one 131080, as for what I understand from reading/debugging the code the reason why during retries the XID is always the same is that the code that branches a XID  is not being run and I could see that

                        such code is always protected with an if asking if the format id is equals to XATxConverter.FORMAT_ID and only when that's true the branching process occurs.

                        Now I 'm trying to run some tests jumping that if statement asking for format ids, that way I guess I could get a different XID on retries but I 'd like to understand what implies to short circuit that if statement asking for format ids.

                         

                        thanks!

                        • 9. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                          tomjenkinson

                          The format ID is used by a transaction manager to work out if its a transaction that it owns (rather than propagated from a different vendor):

                           

                          131077 is our normal JTA

                          131080 is our durable bridge participant ./txbridge/src/main/java/org/jboss/jbossts/txbridge/inbound/BridgeDurableParticipant.java

                          We also use 131072, which is for our JTS


                          Tom

                          • 10. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                            nbarrera

                            Thank you Tom,

                            So what I don't understand now is why would the code provided in XATxConverter.setBranchUID prevent the XID from being modified (branched) when the current transaction has a XID with a format ID different from the normal JTA format ID?

                            • 11. Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                              nbarrera

                              Hi all,

                               

                              I 've good news I was able to get my scenario working agains a single Mysql DBRMS.

                               

                              I was able to make some changes to a couple of wildfly jars which I 'll describe next.

                               

                               

                              I 'd like to say first that I 'm keen on receiving your feedback specially regarding to any side effect (or collateral damage) the modifications I 've done may have related to other parts of the transaction system.

                               

                              The modifications were done specifically to run the code I needed to, and without keeping in mind the implications of this on it's environment.

                               

                               

                              1) First off the problem was that when service B was opening a transaction the mysql connector was throwing an exception without a XA error code (code=0). The mysql rdbms answered with the correct sql error code but the mysql connector had a bug that it wasn't mapping that sql error code 1440 to the corresponding XA errorCode (XAER_DPUID). There is already a forum topic about this (Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists).

                               

                              Updating the mysql-connector to version 5.1.28 fixed this issue.

                               

                               

                              2) After upgrading mysql-connector, I could see a difference in the logs where now I was seeing the correct error message XAER_DPUID but the problem was that while serviceB was trying to make XA start and mysql said that the XID already existed jboss just threw the exception and didn't retry with another XID.

                               

                              The problem seemed to be that the error code was treated as failed XA code, and the connection was dropped instead of using it to retry a new XID.

                               

                              I had to modify the ironjacamar jdbc adapter method from the wildfly-8.0.0.CR1/modules/system/layers/base/org/jboss/ironjacamar/jdbcadapters/main/ironjacamar-jdbc-1.1.2.Final.jar jar file

                               

                              org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.isFailedXA(int)

                              //old code
                              
                                 private boolean isFailedXA(int errorCode)
                                 {
                                    return !(errorCode >= XAException.XA_RBBASE && errorCode < XAException.XA_RBEND);
                                 }
                              
                              

                               

                               

                              //modified code
                              
                                 private boolean isFailedXA(int errorCode)
                                 {
                                    return errorCode != XAException.XAER_DUPID && !(errorCode >= XAException.XA_RBBASE && errorCode < XAException.XA_RBEND);
                                 }
                              
                              

                               

                              //older code (from grepcode's version 1.1.0.Final http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.ironjacamar/ironjacamar-jdbc/1.1.0.Final/org/jboss/jca/adapters/jdbc/xa/XAManagedConnection.java#XAManagedConnection.isFailedXA%28int%29)
                              
                                 private boolean isFailedXA(int errorCode)
                                 {
                                    return (errorCode == XAException.XAER_RMERR || errorCode == XAException.XAER_RMFAIL);     
                                 }
                              
                              

                               

                              With "old code" running XAER_DPUID would return true so the connection is discarded.

                               

                              With "modified code" XAER_DPUID would return false, so the connection is not discarded rather an XAException is thrown, that lets another object the oportuninty to recover from that exception by retrying.

                               

                              With "older code" XAER_DPUID would also return false, so.. I don't understand the reason for that change but that change had impact on the TransactionImple code.

                               

                               

                              3) After the last fix I could see the serviceB's XA start retrying 20 times with the same XID. I decided to debug more about XID identifier.

                              I found that method:

                               

                              com.arjuna.ats.internal.jta.xa.XID.toString()

                               

                              introduces some error while printing out the branch qualifier.

                               

                              That class was in the wildfly-8.0.0.CR1/modules/system/layers/base/org/jboss/jts/main/narayana-jts-jacorb-5.0.0.CR2.jar jar file.

                               

                              // old code
                                      stringBuilder.append(", ");
                                      for (int i = 0; i < bqual_length; i++) {
                                          stringBuilder.append(gtrid_length + data[i]);
                                      }
                              
                              

                               

                               

                              // modified code
                                      stringBuilder.append(", ");
                                      for (int i = 0; i < bqual_length; i++) {
                                          stringBuilder.append(data[gtrid_length + i]);
                                      }
                              
                              

                               

                               

                              4) While debugging more into XID identifiers I got to the conclusion that (although the branch parameter was setted to true) the code that alters a baseXid by branching it needed to be executed so that

                              retries were done with different identifiers.

                               

                              I saw that there were some if clauses that prevented the baseXid to be modified (branched) and were returning the original baseXid.

                               

                              These if clauses were asking if the current transaction's (_theTransaction) XID has the same FORMAT_ID as XATxConverter.FORMAT_ID (the normal JTA format id as explained by Tom) and only if the

                              formats were the same shall the XID be branched. When formats were different (that was my case) baseXid was returned (again with the same identifier that had just been rejected by "already exists").

                               

                              So my quick/dirty fix here was to ignore those if clauses I 've added a system property and when that property is set to true then those if clauses are ignored that said it will branch even when the XID's format id is different from XATxConverter.FORMAT_ID.

                               

                              I had to modify two classes from the wildfly-8.0.0.CR1/modules/system/layers/base/org/jboss/jts/main/narayana-jts-jacorb-5.0.0.CR2.jar jar file.

                               

                               

                              com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple

                               

                              // old code
                              
                                  @Override
                                  protected Xid createXid(boolean branch, XAModifier theModifier, XAResource xaResource) throws IOException, ObjectStoreException
                                  {
                                      Xid xid = baseXid();
                                     
                                      // We can have subordinate XIDs that can be editted
                                      if (xid.getFormatId() != XATxConverter.FORMAT_ID)
                                          return xid;
                                   ...
                              
                              

                               

                              // modified code
                              
                                  @Override
                                  protected Xid createXid(boolean branch, XAModifier theModifier, XAResource xaResource) throws IOException, ObjectStoreException
                                  {
                                      Xid xid = baseXid();
                                      String mysqlPassthrough = System.getProperty("mysql.xa.dpuid.passthrough", "false");
                                      // We can have subordinate XIDs that can be editted
                                      if ( !"true".equalsIgnoreCase(mysqlPassthrough) && xid.getFormatId() != XATxConverter.FORMAT_ID)
                                          return xid;
                                  ...
                              
                              

                               

                               

                              com.arjuna.ats.jta.xa.XATxConverter

                               

                              // old code
                              
                                  public static void setBranchUID(XID xid, Uid uid) {
                                      if (xid == null || xid.formatID != FORMAT_ID) {
                                          return;
                                      }
                              
                                      byte[] bqual = uid.getBytes();
                                      System.arraycopy(bqual, 0, xid.data, xid.gtrid_length, Uid.UID_SIZE);
                                  }
                              
                              

                               

                              // modified code
                              
                                  public static void setBranchUID(XID xid, Uid uid) {
                                      if (xid == null || ( !"true".equalsIgnoreCase(System.getProperty("mysql.xa.dpuid.passthrough"))  && xid.formatID != FORMAT_ID)) {
                                          return;
                                      }
                              
                                      byte[] bqual = uid.getBytes();
                                      System.arraycopy(bqual, 0, xid.data, xid.gtrid_length, Uid.UID_SIZE);
                                  }
                              
                              

                               

                               

                               

                               

                              Finally run wildfly with -Dmysql.xa.dpuid.passthrough=true in JAVA_OPTS and worked.

                               

                              Note that with the modified code I can't see any retries I guess it is because now it's always branching so it never finds a duplicate XID ( I don't know if this could be a problem )

                               

                               

                              Thank you for your help, and I 'm waiting for your comments about my changes to your code if you need it I could fill any JIRA about this subject you ask me to.

                               

                              Cheers,

                               

                              Nicolas.-

                              • 12. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                                tomjenkinson

                                Hi Nicolas,

                                 

                                Thanks for the very detailed update, I will go through your comments in turn:

                                 

                                1. understood

                                2. Sounds like a JCA bug, you could raise that over here: https://issues.jboss.org/browse/JBJCA

                                3. Good catch, I will fix the issue, or if you would like your name in lights, sign the CLA over here: Contributor License Agreements - JBoss Community (project is JBoss Transactions) and then raise a pull request over here: https://github.com/jbosstm/narayana/

                                4. We will need to get robinpau and gytis to take a look at this, but conceptually something like "if supportedFormatIds.contains(formatID)" where supportFormatIds = new ArrayList(new Integer[{131077}, {131080}]); might work. That being said, its possible that bridging intentionally does not allow the branch to be changed in which case one of those guys will be able to suggest a way forward.

                                 

                                Tom

                                • 13. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                                  marklittle

                                  Tom, with item 3 let's figure out if the code contributed is the right code to add. I'm not convinced it is. However, I'm also not sure why we have the code that's in there already. It'd be worth finding out when that was added and why, because I don't appear to see it in much older versions of JBossTS.

                                  • 14. Re: Re: XAER_DUPID: The XID already exists (even with new mysql connector)
                                    nbarrera

                                    Thank you Tom for your prompt answer,

                                    2. Sounds like a JCA bug, you could raise that over here: https://issues.jboss.org/browse/JBJCA

                                    Ok, I 'll fill the JIRA there... I 'll mention the connection with JBTM.

                                     

                                    3. Good catch, I will fix the issue, or if you would like your name in lights, sign the CLA over here: Contributor License Agreements - JBoss Community (project is JBoss Transactions) and then raise a pull request over here: https://github.com/jbosstm/narayana/

                                    I 'll accept your invitation to sign the CLA and try a pull request, thanks!

                                    4. We will need to get Paul Robinson and Gytis Trikleris to take a look at this, but conceptually something like "if supportedFormatIds.contains(formatID)" where supportFormatIds = new ArrayList(new Integer[{131077}, {131080}]); might work. That being said, its possible that bridging intentionally does not allow the branch to be changed in which case one of those guys will be able to suggest a way forward.

                                    Ok, I 'll wait for their insight about these formatID identifiers.

                                     

                                     

                                    I 'll take holidays next week so most probably I 'll stay mute during that period but as soon I get back I 'll be focused on this again.

                                     

                                    thank you all!

                                    1 2 Previous Next