The JMS resource adapter detects the connection failure through the exception listener and JMS operations. When a WebLogic Server instance failure is detected, the corresponding connections and sessions are closed and new ones are created. The failed connections are purged from the connection pool to prevent them from being reused.
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 to restarted instances.
When a WebLogic Server distributed destination member fails, the JMS resource adapter for the inbound MDB container closes any existing connections and sessions and opens new ones to an available cluster member.
If the failed cluster member is restored, or a new member is added, the JMS resource adapter 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 and DOWN events to achieve the rebalance. To obtain this behavior, you must disable server affinity and enable load balancing. For information, see Load Balancing for JMS in Administering Clusters for Oracle WebLogic Server.
For failures that cannot be recovered from quickly, the adapter logs the failure and retries periodically.
The following topics provide information about the transaction recovery process when a foreign application server or WebLogic Server becomes unavailable before a transaction is complete:
This section provides information about how a transaction directed by a foreign transaction manager is processed when the WebLogic Server instance is unavailable.
Failure before prepare
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.
Failure after prepare
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 Server 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 Developing JTA Applications for Oracle WebLogic Server and InterposedTransactionManager in Java API Reference for Oracle WebLogic Server.
If the foreign transaction manager uses the same XAResource to complete the transaction, the JMS resource adapter XAResource wrapper looks up 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 completed only after 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 and rollback calls for all in-doubt transactions either by itself or by forwarding to the responsible ITM.
See Cluster-Wide Recovery in Developing JTA Applications for Oracle WebLogic Server for more information.
Note:
For the recovery process to succeed, every ITM in the cluster must be available because all ITMs in the cluster are polled to compile the complete list of in-doubt transactions.
The foreign transaction manager interacts with the XAResource wrapper provided by the JMS resource adapter. The XAResource wrapper relays the XA calls to ITM stubs. The JMS resource adapter uses the standard JMS API and the proprietary WebLogic JMS extension API as the client interface. An application such as a EJB or servlet that is running inside the foreign server interacts with the JMS resource adapter and WebLogic JMS through JMS resource adapter wrappers. In addition to relaying the JMS operations to WebLogic Server client objects, the JMS resource adapter wrappers also perform lazy enlistment and end transaction branches by intercepting the appropriate JMS calls.
The following topic provides information about JMS resource adapter behavior during WebLogic Server service migration.
If a WebLogic JMS server is configured to use a migratable target, a JMS resource adapter instance reconnects to the migrated WebLogic JMS service after a service migration is completed.
Note:
WebLogic JMS service migration provides high availability for JMS services, but it does not provide load balancing.
See Migratable Services in Administering Clusters for Oracle WebLogic Server for more information.
Note the following details regarding how the JMS resource adapter handles inbound and outbound communication during JMS service migration:
Inbound communication
During JMS service migration, the JMS resource adapter 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.
Outbound communication
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 resource adapter detects the migration and redirects JMS operations to the new migrated destination members.