Always Catch exceptions Use Transactions to Group Message Work JMS Clients Should Always Call the close Method

14-10 Programming JMS for Oracle WebLogic Server

14.1.4 Explicitly Disabling Automatic Failover on JMS Clients

If you do not want your JMS clients to be automatically reconnected, then you must explicitly disable this feature either programatically or administratively.

14.1.4.1 Programmatically

If you do not want your JMS clients to be automatically reconnected, then your applications should call the following code: ConnectionFactory cf = javax.jms.ConnectionFactoryctx.lookup JNDI name of connection factory javax.jms.Connection con = cf.createConnection; weblogic.jms.extensions.WLConnectioncon.setReconnectPolicynone For more information about the setReconnectPolicy method, refer to the weblogic.jms.extension.WLConnection API.

14.1.4.2 Administratively

Administrators that do not want JMS clients to automatically reconnect should use the following steps to disable the Reconnect Policy on the JMS connection factory: 1. Follow the directions for navigating to the JMS Connection Factory: Configuration: Client pages, see Configure connection factory client parameters in the Oracle WebLogic Server Administration Console Help.

2. In the Reconnect Policy field, select None to disable the JMS client reconnect

feature on this connection factory. For more information about the Reconnect Policy field, see JMS Connection Factory: Configuration: Client in the Oracle WebLogic Server Administration Console Help. 3. Click Save. For more information about the other JMS connection factory client parameters, see ClientParamsBean in the Oracle WebLogic Server MBean Reference.

14.1.5 Best Practices for JMS Clients Using Automatic Failover

Oracle recommends the following best practices for JMS clients when using the Automatic JMS Client Reconnect feature:

14.1.5.1 Always Catch exceptions

There are some connection failure scenarios where the result of a message operation is undetermined and WebLogic Server throws an exception. Your application must deal with the exception appropriately. See: ■ Section 14.1.1, Automatic Reconnect Limitations ■ Section 14.1.2.5.1, Special Cases for Reconnected Sessions ■ Section 14.1.2.6.1, Special Case for Distributed Destinations

14.1.5.2 Use Transactions to Group Message Work

Use transacted sessions JMS or user transactions JTA to group related or dependent work, including messaging work, so that either all of the work is completed or none of it is. If a server instance goes down and a message is lost in the middle of a transaction, Recovering from a Server Failure 14-11 the entire transaction is rolled back and the application does not need to make a decision for each message after a failure.

14.1.5.3 JMS Clients Should Always Call the close Method

As a best practice, your applications should not rely on the JVMs garbage collection to clean up JMS connections because the JMS automatic reconnect feature keeps a reference to the JMS connection. Therefore, always use connection.close to clean up your connections. Also consider using a Finally block to ensure that your connection resources are cleaned up. Otherwise, WebLogic Server allocates system resources to keep the connection available. For more information closing JMS client connections, see Section 6.7.6, Best Practice: Always Close Failed JMS ClientIDs.

14.2 Programming Considerations for WebLogic Server 9.0 or Earlier Failures

JMS client applications running on WebLogic Server 9.0 or earlier had to reestablish javax.jms objects after a server failure. If you are still running release 9.0 or earlier JMS clients, you may want to program your JMS clients to terminate gracefully in the event of a server failure. For example:

14.3 Manually Migrating JMS Data to a New Server

WebLogic JMS uses the migration framework to allow WebLogic JMS respond properly to migration requests and bring a WebLogic JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure. Once properly configured, a JMS server and all of its destinations can migrate to another WebLogic Server within a cluster. Howeer, you can manually recover JMS data from a failed WebLogic Server by starting a new server and doing one or more of the tasks in Table 14–1 . Tip: Be aware of transaction commit failures after a server reconnect, which may occur if the transaction subsystem cannot reach all the participants involved in the transaction. Table 14–2 Programming Considerations for Server Failures If a WebLogic Server Instance Fails and... Then... You are connected to the failed WebLogic Server instance A JMSException is delivered to the connection exception listener. You must restart the application once the server is restarted or replaced. A JMS Server is targeted on the failed WebLogic Server instance A ConsumerClosedException is delivered to the session exception listener. You must re-establish any message consumers that have been lost.