Programming WebLogic JMS

Recovering from a WebLogic Server Failure

The following sections describe how to terminate a JMS application gracefully if a server fails and how to migrate JMS data after server failure.

Programming Considerations

You may want to program your JMS application to terminate gracefully in the event of a WebLogic Server failure. For example:

Table 13-1 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.

Migrating JMS Data to a New Server

WebLogic JMS uses the migration framework implemented in the WebLogic Server core, which allows 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.

You can recover JMS data from a failed WebLogic Server by starting a new server and doing one or more of the tasks in Table 13-2.

Note: There are special considerations when you migrate a service from a server instance that has crashed or is unavailable to the Administration Server. If the Administration Server cannot reach the previously active host of the service at the time you perform the migration, see Migrating a Service When Currently Active Host is Unavailable in Using WebLogic Server Clusters.

Table 13-2 Migration Task Guide

If Your JMS Application Uses. . .	Perform the Following Task. . .
Persistent messaging—JDBC Store	If the JDBC database store physically exists on the failed server, migrate the database to a new server and ensure that the JDBC connection pool URL attribute reflects the appropriate location reference. If the JDBC database does not physically exist on the failed server, access to the database has not been impacted, and no changes are required.
Persistent messaging—File Store	Migrate the file to the new server, ensuring that the pathname within the WebLogic Server home directory is the same as it was on the original server.
Transactions	To facilitate recovery after a crash, WebLogic Server provides the Transaction Recovery Service, which automatically attempts to recover transactions on system startup. The Transaction Recovery Service owns the transaction log for a server. For detailed instructions on recovering transactions from a failed server, see "Transaction Recovery After a Server Fails" in Programming WebLogic JTA.

If Your JMS Application Uses. . .

Perform the Following Task. . .

Persistent messaging—JDBC Store

If the JDBC database store physically exists on the failed server, migrate the database to a new server and ensure that the JDBC connection pool URL attribute reflects the appropriate location reference.

If the JDBC database does not physically exist on the failed server, access to the database has not been impacted, and no changes are required.

Persistent messaging—File Store

Migrate the file to the new server, ensuring that the pathname within the WebLogic Server home directory is the same as it was on the original server.

Transactions

To facilitate recovery after a crash, WebLogic Server provides the Transaction Recovery Service, which automatically attempts to recover transactions on system startup. The Transaction Recovery Service owns the transaction log for a server.

For detailed instructions on recovering transactions from a failed server, see "Transaction Recovery After a Server Fails" in Programming WebLogic JTA.

Note: JMS persistent stores can increase the amount of memory required during initialization of WebLogic Server as the number of stored messages increases. When rebooting WebLogic Server, if initialization fails due to insufficient memory, increase the heap size of the Java Virtual Machine (JVM) proportionally to the number of messages that are currently stored in the JMS persistent store and try the reboot again.

For information about starting a new WebLogic Server, see the "Starting and Stopping Servers: Quick Reference". For information about recovering a failed server, refer to Avoiding and Recovering From Server Failure in Managing Server Startup and Shutdown.

For more information about defining migratable services, see "Service Migration" in Using WebLogic Server Clusters.