-
15. Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
tomjenkinson Nov 5, 2012 10:44 AM (in response to tomjenkinson)By the way, the reason this circumstance can occur is because the node name isn't encoded in the branch. That is why we retry a set number of times as the same tx global transaction id will be used at multiple servers.
The branch qualifier is composed of:
host (going to be the same on your set up)
pid (for your configuration this is UUID.randomUUID)
uid.initTime (to a second resolution - this is not so accurate, right)
an incremental counter starting a zero
All these can possibly be equal in an seemingly unlikely situation, the main cause of uniqueness coming from the UUID.randomUUID. If this is not so random and you create a branch at the same second on each node they will get the same value, hence the retry which will roll them forward at different rates (as some succeed).
It may make sense to use the xa node name (if it set) rather than the host name and pid for constructing Uids (or at least bqual uids), I have created a Jira for that: https://issues.jboss.org/browse/JBTM-1337
-
16. Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
tomjenkinson Nov 5, 2012 10:52 AM (in response to tomjenkinson)I should add, I would use Postgres if I was you, definitely recommented until http://bugs.mysql.com/bug.php?id=12161 is resolved.
-
17. Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
tomjenkinson Nov 6, 2012 8:42 AM (in response to tomjenkinson)Hi Matt,
Having reviewed the matter internally we think we have a handle on this now.
Although the issue I described I do believe still exists, it is not what is causing your problem.We believe that although you have correctly configured the container for JTS mode, by using EJB remoting3 rather than iiop, you are actually utilising the JTS in "distributed JTA" mode. This leverages the TX inflow capabilities of JCA to propagate the XID to the servers, rather than CORBA. This is fine in and of itself when you only access an RM from a single server per transaction, unfortunately you are trying to access the same RM at multiple nodes within the same transaction which due to limitations of the JCA specification will not work.
You have a few alternatives:
1. Pin usage of an RM to a single server - this is likely to be extremely invasive to your application architecture and unviable
2. Use JTS. To do this you need to lookup your EJBs using the standard CORBA Home/Remote interfaces, you can see a nice simple example of this here: https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/jts
Of interest you can see the client looking up the remote EJB here: https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/jts/application-component-1/src/main/java/org/jboss/as/quickstarts/cmt/jts/ejb/CustomerManagerEJB.java
The EJB needs a home interface: https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/jts/application-component-2/src/main/java/org/jboss/as/quickstarts/cmt/jts/ejb/InvoiceManagerEJBHome.java
It has an EJB implementation: https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/jts/application-component-2/src/main/java/org/jboss/as/quickstarts/cmt/jts/ejb
It has a remote interface to access the EJB: https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/jts/application-component-2/src/main/java/org/jboss/as/quickstarts/cmt/jts/ejb/InvoiceManagerEJB.java
You need to configure the EJB name in the CORBA naming service (note, its not JNDI)
Finally, the way we can tell you are using JCA is you have added a lot of EJB remoting configuration that is not required, you should consider making the following changes to be sure you are using EJB:
1. Remove the ejb-security-realm:
<security-realm name="ejb-security-realm"
<server-identities
<secret value="dGVzdA=="/
</server-identities
</security-realm
2. Revert the remoting-connector:
<connector name="remoting-connector" socket-binding="remoting"/
<outbound-connections
<remote-outbound-connection name="remote-ejb-connection" outbound-socket-binding-ref="remote-ejb" username="ejb" security-realm="ejb-security-realm"
<properties
<property name="SASL_POLICY_NOANONYMOUS" value="false"/
<property name="SSL_ENABLED" value="false"/
</properties
</remote-outbound-connection
<remote-outbound-connection name="remote-ejb-connection-b" outbound-socket-binding-ref="remote-ejb-b" username="ejb" security-realm="ejb-security-realm"
<properties
<property name="SASL_POLICY_NOANONYMOUS" value="false"/
<property name="SSL_ENABLED" value="false"/
</properties
</remote-outbound-connection
<remote-outbound-connection name="remote-ejb-connection-c" outbound-socket-binding-ref="remote-ejb-c" username="ejb" security-realm="ejb-security-realm"
<properties
<property name="SASL_POLICY_NOANONYMOUS" value="false"/
<property name="SSL_ENABLED" value="false"/
</properties
</remote-outbound-connection
</outbound-connections
Back to:
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/
3. Remove the additional socket bindings:
<outbound-socket-binding name="remote-ejb"
<remote-destination host="localhost" port="4547"/
</outbound-socket-binding
<outbound-socket-binding name="remote-ejb-b"
<remote-destination host="localhost" port="4647"/
</outbound-socket-binding
<outbound-socket-binding name="remote-ejb-c"
<remote-destination host="localhost" port="4747"/
</outbound-socket-binding
Hope this helps,
Tom
-
18. Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
paul.robinson Nov 8, 2012 6:20 AM (in response to tomjenkinson)Thanks for this Tom.
I've managed to reproduce Matt's issue and I'm in the process of making the changes you suggest.
I was wondering, is it possible to prevent the AS defaulting to "distributed JTA"? This may be a simpler approach with lower impact on our students who are already using the EJB Remoting3.
Paul.
-
19. Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
tomjenkinson Nov 8, 2012 6:23 AM (in response to paul.robinson)Hi Paul,
The default *is* CORBA really, if you look at the changes you are going to be making, most of them are to remove your remoting config and to use CORBA lookups as per standard JEE.
You have enabled the EJB Remoting3 transport, you are now effectively going to disable it and just use IIOP. EJB remoting3 is great, but not for interfacing with the same RM on different nodes, not that I would recommend doing that architecturally anyway.
Tom
-
20. Re: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_DUPID: The XID already exists
tomjenkinson Nov 8, 2012 6:57 AM (in response to tomjenkinson)Sorry, I missed the link to where you configure the name: https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/jts/application-component-2/src/main/resources/META-INF/jboss-ejb3.xml
An exercise for the reader is to work out what the default name of beans are, then raise a pull request on my quickstart so we don't need an jboss-ejb3.xml.
i.e. your pull should be able to remove jboss-ejb3.xml and point https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/jts/application-component-1/src/main/java/org/jboss/as/quickstarts/cmt/jts/ejb/CustomerManagerEJB.java at the correct name, I couldn't work out the default naming pattern so fixed it in the jboss-ejb3.xml but I would rather just use the default