2 Replies Latest reply on Jul 17, 2012 11:40 AM by Jonathan Halliday

    Can the JBoss JCA support multiple XAResources?

    ShuiXin Zhang Newbie

      Hi all,

      I have a connector based on JCA. I am confused on the inflow transaction issue.

      I construct a XID and submit the work to work manager. The work will access the same database twice, and they will use 2 XAResources. I configured that all XAResource are not belong to same RM.

      The first XAResource can work fine, but the second XAResource will use the same XID to start, it is failed.

       

      I noticed that the TransactionImple will use com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple, its createXid method will use the below code, it will use the old one.

       

      I want to confirm that JCA subordinator can only include one XAResource? If it is no, how can I do it?

       

       

          private final Xid createXid(boolean branch, XAModifier theModifier)
          {
              Xid xid = baseXid();
        
              if (xid != null)
                  return xid;
        
              xid = new XidImple(_theTransaction, branch);
        
              if (theModifier != null)
              {
                  try
                  {
                      xid = theModifier.createXid((XidImple) xid);
                  }
                  catch (Exception e)
                  {
                      e.printStackTrace();
                  }
              }
        
              return xid;
          }
      

       

       

      public final Xid baseXid ()
      {
          return ((SubordinateAtomicAction) _theTransaction).getXid();
      }
      

       

      It's my start transaction code snippet.

       

      ResourceAdapterImpl ra = (ResourceAdapterImpl)notifier_.getResourceAdapter();
      BootstrapContext ctx = ra.getContext();
      Xid xid = getXid(tid);
      WorkManager workMgr = ctx.getWorkManager();
      ExecutionContext ectx = new ExecutionContext();
      ectx.setXid(xid);
      MyWork work = new MyWork(this, events);
      workMgr.doWork(work, WorkManager.INDEFINITE, ectx, work);
      

       

      I use JBossTS 4.2.3 SP5 C09.

        • 1. Re: Can the JBoss JCA support multiple XAResources?
          ShuiXin Zhang Newbie

          Does anyone know this?

          The XID of subordinator will use the same one, the branch Id is also same?

          • 2. Re: Can the JBoss JCA support multiple XAResources?
            Jonathan Halliday Master

            > I have a connector based on JCA. I am confused on the inflow transaction issue.

             

            You're not the only one - the JCA spec committee seem to have a few problems with it too. :-)

             

            The current braindead JCA inflow spec is such that the TM has no option but to use the provided Xid verbatim. There needs to be a provision to pass in a mask that effectively delegates part of the Xid space to the subordinate TM so that it can allocation new branches in that subspace. Think IP address block allocation hierarchies...  But that's unlikely to happen until Java EE 8 at the earliest, so meanwhile we get along as best we can.

             

            > I construct a XID and submit the work to work manager. The work will access the same database twice, and they will use 2 XAResources.

            > I configured that all XAResource are not belong to same RM.

            > The first XAResource can work fine, but the second XAResource will use the same XID to start, it is

             

            You're making life hard for yourself. The state machine for the Xid is per-RM. If two XAResources return isSameRM false, they are assumed to maintain independent state machines for the Xid and hence it's reasonable to expect that the start should work on both. Indeed as long as they don't communicate with eachother, each can happily work with the same Xid. It's the TM that's the real problem and even then only in recovery situations. Essentially the TM can't track branch completion properly because it assumes one state machine per Xid but actually actually needs N state machines, one per RM-Xid tuple. The new metadata support in the logs will eventually enable that, but it's not done yet. JBTM-622