1 Reply Latest reply on Mar 12, 2006 11:14 AM by starksm64

    JmsXA not working across distributed JBoss servers

    erik777

      We're using Jboss 4.0.2 and currently support a single instance install of JBoss. We are using XA datasources using DataDirect and SQL Server.

      We're attempting to support distributing our applications among different instances of JBoss to better manage load. Our tests have all passed in this area except one, JMS XA transactions. We use CMT and JmsXA.

      Our test goes like this. Remote method on Stateless Session Bean A in JBoss instance 1 is invoked, and it calls Stateless Session Bean B in another ear, which then uses JmsXA to post it to a queue within the same JBoss instance. Stateless Session Bean A then throws a RuntimeException causing a rollback

      If we run the above test in a single JBoss instance, it works perfectly. The post to the queue is never committed and the MDB never receives the message. If we run the test with Session Bean B in another JBoss instance, with Session Bean A remotely invoking Session Bean B, then it fails to rollback the posting of the message, causing the MDB to erronesouly receive the message.

      The only difference in the tests is whether or not Session Bean A finds Session Bean B in the same server or in a remote server. Even if it is it is in the same instance, it uses the remote interface and supplies a PROVIDER_URL in the environment during the lookup. It is oblivious and runs the same regardless of where Session Bean B is located

      Has anyone been able to get this type of configuration to properly rollback? If so, how did you configure it? Will using HA-JNDI/JMS solve the problem? That's a costly step for us as we have a lot of custom configuration and technological dependencies. Right now though we need to get this to work in order to be able to distribute our applications across JBoss instances.

      We had the same failure to do an XA rollback when we used OIL2 or UIL2 instead of JmsXA in a single JBoss instance. However, in this case, we're using JmsXA and it now works in a single instance. It appears as though the remote session bean invocation is not participating in the XA transaction correctly.