jms-spec
  1. jms-spec
  2. JMS_SPEC-105

Provide API to allow an app server or resource adapter to obtain a XAResource from a JMSContext

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0PD
    • Fix Version/s: 2.0PD, 2.0
    • Labels:
      None

      Description

      JMS 1.1 defined an optional API to allow an application server or resource adapter to obtain a XAResource object corresponding to a Session object. This is the "chapter 8" API, which defines the optional interfaces XAConnectionFactory, XAConnection, XASession and the method XASession#getXAResource().

      However there is currently no equivalent API to allow an application server or resource adapter to obtain a XAResource object corresponding to a JMSContext object.

      This means that an application server which uses the "chapter 8" API to integrate with a JMS provider (rather than using a resource adapter) cannot support JMSContext properly. The same applies for a generic resource adapter which uses the "chapter 8" API to integrate with any JMS provider.

      There are two alternatives:

      Option 1

      This option follows the same approach as the existing "chapter 8" API

      • Add four new new createXAContext methods to XAConnectionFactory. These are similar to the four existing createContext methods on ConnectionFactory except that they return a XAJMSContext rather than a JMSContext
      • Define a new interface XAJMSContext. This is a subtype of JMSContext with one additional method, getXAResource, which returns a XAResource.

      Option 2

      • Simply add a new method getXAResource to the JMSContext

      In both cases implementation of the new interfaces and methods would be optional just like the rest of the existing "chapter 8" API is.

      It is proposed that option 1 be adopted, but option 2 is mentioned as a possible alternative.

      Note that even though the chapter 8 API is optional, and JMS 2.0 encourages the use of a the JCA API rather than the chapter 8 API for integration of a JMS provider and an application server, the chapter 8 API continues to be part of JMS and is valued by some vendors. If we did not implement this change then we would effectively be breaking this API by making it unusable with JMSContext objects.

        Issue Links

          Activity

          Hide
          clebertsuconic added a comment -

          Another issue I constantly face over Transactions is... Most Transaction Managers will offer a recovery option, and currently there's no way to register the XAResource to be recovered. There's no public API that would allow that. it would be nice if we could address that. But I think this will probably go beyond the scope of JMS.

          Show
          clebertsuconic added a comment - Another issue I constantly face over Transactions is... Most Transaction Managers will offer a recovery option, and currently there's no way to register the XAResource to be recovered. There's no public API that would allow that. it would be nice if we could address that. But I think this will probably go beyond the scope of JMS.
          Hide
          Nigel Deakin added a comment -

          @clebert: Do you mean there is no standard way for a transaction manager performing recovery to obtain all the XAResource objects it needs to use for recovery? If so then this is more than a JMS issue.

          Show
          Nigel Deakin added a comment - @clebert: Do you mean there is no standard way for a transaction manager performing recovery to obtain all the XAResource objects it needs to use for recovery? If so then this is more than a JMS issue.
          Hide
          nwright added a comment -

          If I understand, it looks like we'd need a hook on the transaction manager API to actively tell it that we (a JMS resource) are a candidate for XA recovery. In which case this does go beyond the scope of JMS, who can we talk to from the JTA spec about this?

          I may have the wrong end of the stick however

          Show
          nwright added a comment - If I understand, it looks like we'd need a hook on the transaction manager API to actively tell it that we (a JMS resource) are a candidate for XA recovery. In which case this does go beyond the scope of JMS, who can we talk to from the JTA spec about this? I may have the wrong end of the stick however
          Hide
          Nigel Deakin added a comment -

          This issue is resolved in the JMS 2.0 final release. Marking issue as resolved with a "fix version" of 2.0

          Show
          Nigel Deakin added a comment - This issue is resolved in the JMS 2.0 final release. Marking issue as resolved with a "fix version" of 2.0

            People

            • Assignee:
              Nigel Deakin
              Reporter:
              Nigel Deakin
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: