This chapter describes transaction processing and recovery when using the JMS RA to interoperate between a foreign application server and WebLogic Server 12.1.3.
This chapter includes the following sections:
There are two major use cases for JMS in a third party application server. Case one is outbound communication where users interact with the JMS provider synchronously. The second case is inbound communications where the users interact with the JMS provider asynchronously, for example through message-driven bean (MDB).
JMS RA provides outbound XA capability for applications using WebLogic JMS according to the JCA standard. See transaction-support.
The JMS RA's managed connection holds a WebLogic JMS client connection and session pointing to a WebLogic cluster member. The managed connection also references the interposed transaction manager (ITM) stub pointing to the same WebLogic cluster member. Although a WebLogic ITM is able to handle JMS operations occurring at different WebLogic instances, it is more efficient to have JMS operations and the ITM located on the same cluster member e same instance (ITM affinity). When a JMS RA's managed connection is involved in a global transaction:
The GlassFish server instance calls the getXAResource() method on the managed connection to enlist its operations into the global transaction (per JCA 1.6 transaction contract between resource adapter and application server).
If Cluster-wide Recovery is enabled, the interposed transaction manager transparently handles any XA calls and forwards them to the correct cluster member instance to maintain ITM affinity. See "Cluster-wide Recovery" in Oracle Fusion Middleware 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.
In the inbound use case, messages are received by implementing either the resource adapter inbound communication contract or native MDB code.
In the resource adapter contract is used, 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 which includes the ITM stub pointing to the same WebLogic server instance as the WebLogic JMS session receiving messages. If the WebLogic destination is a distributed destination, the worker threads are distributed evenly across the destination members.
If native MBDs are use, the application server is responsible for the message receiving. The use scenario of the JMS resource adapter is the same as 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, or "eagerly", enlisted in the transaction. This is true even if the connection is ultimately unused, 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— only if data is transmitted through the connection.
Both a JMS RA and an 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 interposed transaction managers of a cluster by selecting the Enable Cluster-Wide Recovery attribute on the "Cluster: Configuration: JTA" page in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
When enabled, each interposed transaction manager in a WebLogic cluster is aware of the transaction distribution across the entire cluster. This allows the interposed transaction manager on each cluster member to determine if it should handle a given XA call or forward it to the appropriate interposed transaction manager on another cluster member.
For additional information on WebLogic transaction processing, see: Understanding Failure Management and "Participating in Transactions Managed by a Third-Party Transaction Manager" in Oracle Fusion Middleware Developing JTA Applications for Oracle WebLogic Server.