2 Replies Latest reply on Jul 8, 2010 3:01 PM by 782601

    Messaging Pattern: Making it XA transactional within a JEE container


      The Messaging Pattern is transactional in so far as a subscriber can turn off autocommit, and a message will only be removed from a queue when the subscriber makes a call to commit. If the subscriber dies before calling commit, the message will be put back on the queue.

      However in a transactional environment i would like to ensure the commit is in sync with my database. If i make a call to commit in my application code, there is an edge case where a plane crashes into the data center after the commit to the subscriber is called, but before my application code returns and the container commits the database transaction.

      Coherence has the ability to participate in XA transactions as a last to commit resource. Would this make the commit to the subscriber participate in the XA transaction, or does the messaging pattern not use coherence transactions in an XA compatible manner?

      Otherwise i would have to use nested transactions in the container code to read the message, process it in a child transaction, then commit the queue read after the child transaction completes. The edge case here is a load of work to handle possible duplicate messages, but that's better than lost messages. XA transactions would be even better.

        • 1. Re: Messaging Pattern: Making it XA transactional within a JEE container
          Brian Oliver-Oracle
          Hi Dan,

          Thanks for the question.

          Currently the Messaging Pattern implementation does not use/implement JTA/XA or Coherence transactions. It's much like regular JMS in that it provides it's own transaction framework, that neither uses JTA or XA. While the JMS specification provides an XA API, the implementation of this is optional, as are Queues or Topics.

          The original goal of the Messaging Pattern implementation was to demonstrate that JMS-like messaging is possible with Coherence. When we looked at constructing the Messaging example, most people we talked to said they didn't want JMS and especially they didn't want transactions. They simply wanted a simple messaging implementation. So it's initial goal was to demonstrate a high-scalable messaging layer. Unfortunately that meant no "real" transaction support, especially in terms of things like XA and/or JTA.

          That said given the way that the pattern is currently implemented one could easily implement an XA resource so that it could be used as a last resource. That's probably the quickest way to get what you would like at the moment.

          Of course I'm certainly interested in implementing XA support, but we know that is non-trivial. It's not currently on our roadmap for the pattern, but it could be. Our next release will provide persistent messaging, but we could investigate XA after that.

          -- Brian

          Brian Oliver | Architect | Oracle Coherence Engineering
          Oracle Fusion Middleware
          • 2. Re: Messaging Pattern: Making it XA transactional within a JEE container
            Thanks very much for the response. We'll take this into consideration with our design.