There are two major use cases for JMS in a third party application server. One use case involves outbound communication where users interact with the JMS provider synchronously. The other use case involves inbound communications where users interact with the JMS provider asynchronously; for example, through a message-driven bean (MDB).
The JMS resource adapter provides outbound XA capability for applications using WebLogic JMS in accordance with the Java Connector Architecture specification. The JMS resource adapter's managed connection holds a WebLogic JMS client connection and session pointing to a WebLogic Server cluster member. The managed connection also references the interposed transaction manager (ITM) stub pointing to the same WebLogic Server cluster member. Although a WebLogic ITM is able to handle JMS operations occurring in different WebLogic Server instances, it is more efficient to have JMS operations and the ITM located on the same cluster member and same instance (ITM affinity).
When a the managed connection for a JMS resource adapter is involved in a global transaction, note the following:
The Oracle GlassFish server instance invokes the getXAResource
method on the managed connection to enlist its operations into the global transaction (in accordance with the Java Connector Architecture transaction contract between a resource adapter and an application server).
If cluster-wide transaction recovery is enabled, the ITYM transparently handles any XA calls and forwards them to the correct cluster member instance to maintain ITM affinity.
For information about how to configure cluster-wide transaction recovery of distributed transactions across all the ITMs of a cluster, see Cluster-Wide Recovery in Developing JTA Applications for Oracle WebLogic Server.
The managed connection returns a XAResource
wrapper pointing to the corresponding ITM.
The wrapper relays the XA calls to the ITM's XAResource
wrapper.
In the inbound use case, messages are received by implementing either the resource adapter inbound communication contract or native MDB code. Note the following:
If the resource adapter contract is used, then the resource adapter receives messages from the MDB destination (a WebLogic Server destination) and distributes them to MDBs. In most cases, the resource adapter spawns multiple worker threads to receive messages concurrently. Each thread uses a separate endpoint and a separate WebLogic JMS session. For a foreign application server to enlist message receiving operations into a global transaction, the JMS resource adapter creates the endpoint using the MessageEndpointFactory
createEndpoint(XAResource)
method, passing a XAResource
wrapper that includes the ITM stub pointing to the same WebLogic Server instance as the WebLogic JMS session that is receiving messages. If the WebLogic destination is a distributed destination, the worker threads are distributed evenly across the destination members.
If native MBDs are in use, the application server is responsible for receiving messages. The use scenario of the JMS resource adapter is the same as for the outbound usage. The transaction management is also the same.
Typically when an application component requests a connection handle in the context of a transaction, the connection is automatically enlisted in the transaction. This occurs even if the connection is never used, which results in unnecessary overhead.
With lazy enlistment, a new connection is enlisted in the transaction only if it is actually used in the transaction; that is, only if data is transmitted through the connection.
Both a JMS resource adapter and a foreign application server must support lazy enlistment for this feature to be used in your application environment.
You can configure cluster-wide transaction recovery of distributed transactions across all the ITMs of a cluster by selecting Enable Cluster-Wide Recovery in the Cluster: Configuration: JTA page in the WebLogic Server Administration Console.
When cluster-wide recovery is enabled, each ITM in a WebLogic Server cluster is aware of the transaction distribution across the entire cluster. This allows the ITM on each cluster member to determine whether it should handle a given XA call or forward it to the appropriate ITM on another cluster member.
For more information about WebLogic Server transaction processing, see Understanding Failure Management and Participating in Transactions Managed by a Third-Party Transaction Manager in Developing JTA Applications for Oracle WebLogic Server.