This chapter describes how the JMS RA responds to WebLogic Server 12.1.3 and foreign application server failures.
This chapter includes the following sections:
The JMS RA detects the connection failure through the exception listener and JMS operations. When a WebLogic instance failure is detected, the corresponding connections/sessions are closed an new connections and sessions are created. The failed connections are purged from the connection pool to prevent them from being resused.
Note:
When a failed WebLogic server instance is restarted or a new server instance joins the a cluster, the resource adapter does not load balance the existing connections in the pool to the new server or restarted instances.When a WebLogic distributed destination member fails, the JMS RA the inbound MDB container closes any existing connections/sessions and opens new connections/sessions to an available member.
If the failed member is restored or a new member is added, the JMS RA rebalances the workload so that the messages are evenly distributed to all distributed destination members. The JMS resource adapter listens to the destination member UP/DOWN events to achieve the rebalance. Requires Server Affinity=fasle and LoadBalancing=true.
For failures that cannot be recovered from quickly, the adapter logs the failure and retries periodically.
The following sections provide on the transaction recovery process when a foreign application server or WebLogic Server become unavailable before a transaction is complete:
The following sections provide information on how a transaction directed by a foreign transaction manager is processed when the WebLogic Server instance is unavailable.
If the WebLogic Server instance participating in the transaction directed by a third-party transaction manager becomes unavailable before the transaction is prepared, the transaction is lost.
If the WebLogic Server instance participating in the transaction directed by a foreign transaction manager becomes unavailable after the transaction is prepared, the result is an in-doubt transaction.
The foreign transaction manager continues to retry the transaction periodically until one of the following occurs:
The transaction times out and the resources are recovered.
The original WebLogic Server instance becomes available and the transaction is resolved.
If the WebLogic environment supports Cluster-wide Recovery, the transaction is resolved when it is forwarded to the appropriate interposed transaction manager (ITM) on another cluster member. See "Cluster-wide Recovery" in Oracle Fusion Middleware Developing JTA Applications for Oracle WebLogic Server and "InterposedTransactionManager" in Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server.
If the foreign transaction manager uses the same XAResource to complete the transaction, the JMS RA XAResource wrapper lookups the ITM stub each time the retry happens. If the foreign transaction manager uses a different XAResource to complete the transaction, the ITM on the live instance forwards the XA calls to the target instance transparently. In either case, the transaction is only completed when the failed ITM is restored by either a restart or by migration.
The recovery process begins when the foreign server is restarted. If Cluster-wide Recovery is enabled, the ITM of any affected clustered WebLogic Server returns all in-doubt transactions that occurred when the recover method is called. Each ITM handles the XAResource commit/rollback calls for all in-doubt transactions either by itself or by forwarding to the responsible ITM. See "Cluster-wide Recovery" in Oracle Fusion Middleware Developing JTA Applications for Oracle WebLogic Server
Note:
For the recovery process to succeed, every single ITM in the cluster must be available as every ITM in the cluster must be polled to compile the complete list of in-doubt transactions.The foreign transaction manager interacts with the XAResource wrapper provided by the JMS RA. The XAResource wrapper relays the XA calls to ITM stubs. The JMS RA uses the standard JMS API and the proprietary WebLogic JMS extension API as the client interface. An application (such as a EJB or Servlet) running inside the foreign server interacts with the JMS RA and WebLogic JMS through JMS RA wrappers. In addition to relaying the JMS operations to WebLogic client objects, the JMS RA wrappers also perform lazy enlistment and end transaction branches by intercepting the appropriate JMS calls.
The following section provides information on JMS RA behavior during WebLogic service migration.
If a WebLogic JMS server is configured to use a migratable target, a JMS RA instance reconnects to the migrated WebLogic JMS service after a service migration completes.
Note:
WebLogic JMS service migration provides high availability for JMS services, it does not provide load balancing. See "Migratable Services" in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server. For information on load balancing, seeThe following sections provide information how the JMS RA handles inbound and outbound communication during JMS service migration:
During JMS service migration, the JMS RA closes existing WebLogic JMS connections and sessions. New connections and sessions are created that point to WebLogic Server instance where the JMS server and its distributed destination members have migrated.
During JMS service migration, the distributed destination members of a failed WebLogic Server instance are migrated to an available WebLogic Server instance.The WebLogic JMS client associated with the JMS RA detects the migration and redirects JMS operations to the new migrated destination members.