5 Replies Latest reply on Aug 29, 2008 12:19 PM by Mark Little

    ClientUserTransaction and TxPropogation inefficiencies

    Adrian Brock Master

      This isn't really related to the TM, more JBoss's remote UT.

      I've fixed this race condition in the initialisation which Galder found while
      load testing:
      https://jira.jboss.org/jira/browse/JBAS-5904

      While looking at the code, I noticed a couple of other issues
      this thread can be used for discussions:

      Leaving remote initial contexts to be closed by the GC
      https://jira.jboss.org/jira/browse/JBAS-5906

      Inefficient determination of the TPC factory due to "broken" caching
      and duplicate jndi lookups
      https://jira.jboss.org/jira/browse/JBAS-5908

        • 1. Re: ClientUserTransaction and TxPropogation inefficiencies
          Jonathan Halliday Master

          You missed the big one, which is: It won't work with the JTS. Since the JTS is going to be a supported option shortly, we should probably figure out what we want to do about that :-)

          • 2. Re: ClientUserTransaction and TxPropogation inefficiencies
            Adrian Brock Master

             

            "jhalliday" wrote:
            You missed the big one, which is: It won't work with the JTS. Since the JTS is going to be a supported option shortly, we should probably figure out what we want to do about that :-)


            What do you mean? UserTransaction is JTA not JTS.

            The ClientUserTransaction is only a proxy to a real transaction on the server
            so JTS is irrelevant for normal clients.

            If there is a transaction manager on the "client" then we use
            ServerVMClientUserTransaction which is just a wrapper for that JTA implementation.

            UT.begin() -> TM.begin()
            etc.

            Of course whether/how that "client" will propogate the TPC to the real server
            maybe an issue you need to resolve, but it is irrelevant whether
            the transaction was started using the UserTransaction api or some
            other use of the client's TM.

            • 3. Re: ClientUserTransaction and TxPropogation inefficiencies
              Jonathan Halliday Master

              > The ClientUserTransaction is only a proxy to a real transaction on the server so JTS is irrelevant for normal clients

              Unfortunately not. If a normal (i.e. without ORB) client is using UT to communicate to a server and that server is switched from the JTA to the JTS, the client will break. Of course that may be a bug rather than a design issue.

              Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation.

              • 4. Re: ClientUserTransaction and TxPropogation inefficiencies
                Adrian Brock Master

                 

                "jhalliday" wrote:
                > The ClientUserTransaction is only a proxy to a real transaction on the server so JTS is irrelevant for normal clients

                Unfortunately not. If a normal (i.e. without ORB) client is using UT to communicate to a server and that server is switched from the JTA to the JTS, the client will break. Of course that may be a bug rather than a design issue.

                Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation.


                So you're saying the TPC obtained by UserTransactionSessionImpl is not usable
                by the client when JTS is installed on the server?

                 public Object begin(int timeout)
                 throws RemoteException,
                 NotSupportedException,
                 SystemException
                 {
                 TransactionManager tm = getTransactionManager();
                 // Set timeout value
                 tm.setTransactionTimeout(timeout);
                 // Start tx, and get its TPC.
                 tm.begin();
                 Object tpc = getTPCFactory().getTransactionPropagationContext(); // HERE !!!!
                 // Suspend thread association.
                 Transaction tx = tm.suspend();
                 // Remember that a new tx is now active.
                 activeTx.put(tpc, tx);
                 // return the TPC
                 return tpc;
                 }
                


                In that case, it is a bug.

                We probably need some new api to differentiate the two use cases
                of getTPC().

                1) When propogating calls to other servers
                2) When retrieving a TPC usable by a client to control UTs.

                • 5. Re: ClientUserTransaction and TxPropogation inefficiencies
                  Mark Little Master

                   

                  "jhalliday" wrote:

                  Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation.


                  We shouldn't need any current JBossTS code at the client side if the client code indirects through JTS. The client should simply interact with the Current pseudo-object, which we know can be wrapped by a UserTransaction. The current UserTransactions in JBossTS would pull in too much of the JBossTS code. What we had in HP (written by Malik) was a small UT implementation that called directly to Current (or maybe it was TransactionFactory, I can't remember, but in which case it would also be doing thread-to-transaction association). I'll dig around and see if I can still find that code, because it's definitely not in the JBossTS sources at the moment.