Consultor Eletrônico

SUMMARY:

This Solution applies to SonicMQ Versions 3.5 and 4.0. It discusses
the steps necessary to receive messages through a QueueConnection or
TopicConnection in a transacted Session when using Distributed
Transactions (XA).

SOLUTION:

When using distributed transactions, the XAConnection gets the
XA resources while the Connection is used for JMS messaging (as it
would be when not using distributed transactions). To start
receiving messages, you must start the Connection (QueueConnection or
TopicConnection), rather than start the XAConnection
(XAQueueConnection or XATopicConnection).

In SonicMQ, there are two ways to do this:

1) After creating the XAConnection, use the appropriate proprietary
method --
progress.message.jclient.xa.XAQueueConnection.getQueueConnection() or
progress.message.jclient.xa.XATopicConnection.getTopicConnection() --

to start the connection, as shown in the following code sample:

XAQueueConnectionFactory XAQConF = new
javax.jms.XAQueueConnectionFactory(URL);
XAQueueConnection XAConnect = XAQConF(url);
(progress.message.jclient.xa.XAQueueConnection)
XAConnect.getQueueConnection().start();

2) Use the standard Factory methods to create both the XAConnection
and the Connection with the same Factory, and then use the standard
Connection methods to start the Connection, as shown here:

XAQueueConnectionFactory XAQConF = new
javax.jms.XAQueueConnectionFactory(url);
XAQueueConnection XAConnect = XAQConF(url);
QueueConnection connect =
XAConnect.createQueueConnection(user,password);
connect.start();

When you use the standard Factory methods as in the second example
above, the XAConnection and Connection created from the same
XAConnectionFactory are associated with each other, but you can create
only one XAConnection/Connection pair per Factory; you need a new
instance of the Factory for every XAConnection/Connection pair.

EXPLANATION:

SonicMQ implements XAConnection support in this way because of a
problem in the JMS 1.0.2 XA SPI.

Because the JMS XA SPI is an optional part of the JMS specification,
Sun chose to work around this problem in their JMS Reference
Implementation to follow the JMS XA SPI, rather than to fix it.

SonicMQ does the same thing, both to follow the JMS 1.0.2 XA SPI,
and to be consistent with the Sun JMS Reference Implementation.

NOTE: The proprietary XA Interfaces and Classes were omitted from the
SonicMQ 3.5 API Reference.


References to Written Documentation:

SonicMQ 3.5 Programming Guide, Chapter 10, "Distributed Transactions Using XA Resources"

SonicMQ V4 Programming Guide, Chapter 11, "Distributed Transactions Using XA Resources"

SonicMQ 4.0 API Reference