NumRepliesOwedMe and numRepliesOwedOthers

Question

          I would like to know what is the significance of the fields
          numRepliesOwedMe and numRepliesOwedOthers that are associated with a javax.transaction.Transaction.
          I am attempting to diagnose a problem that results in a weblogic.transaction.RollbackException
          due to a transaction timeout. I have verified that increasing the transaction
          time does not solve this problem.
          A specific instance of a Transaction is used in two session beans, A & B, where
          A calls B. In A the values of numRepliesOwedMe and numRepliesOwedOthers are always
          0. In B the values of numRepliesOwedMe and numRepliesOwedOthers are both always
          1. When the call sequence returns to A the values are again 0, but after this
          point a specific SELECT statement "hangs" until the transaction times out.
          I am wondering if these values are significant in helping to identify the cause
          of this problem.
          Thanks,
          Vince
          

Answer 1

Hi,
          Well, transaction guru's please correct what I say here, but from what I
          understand of your problem here goes:
          If you begin a user transaction your are going to be starting a distributed
          transaction. That's the point of doing it, and hence that's why you have an
          XA. You have more than once resource participating in a transaction, and
          that is what UserTransaction was created for. You can't do it with a local
          transaction, which is for one resource only. I hope that answers "why
          would I need a XA". Even if both resources are hosted by WebLogic, you have
          explicitly asked for a UserTransaction...WL will optimize it if both are on
          same server, but still.. In addition, if you have a true XA data source and
          connection pool, then I would imagine that WL would list the transaction
          system of the DB too....whcih won't be local.
          As for your other problem, it seems to me that you have a connection pool of
          connections that are not XA-aware. If you set the attribute in the
          datasource and enable emulation, then the datasource becomes XA aware, but
          only sort of. WL handles the XA behaviour of that resource, but with
          limitations (you can't have more than one resource with XA emulation in the
          same Tx). If you are using a connection factory with a different store that
          uses XA-emulation, as well as straight JDBC from yet another pool using XA
          emulation, then you will also get problems. Best is to use a real driver
          that supports XA.
          Regards,
          Jon