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.
14-12 Programming JMS for Oracle WebLogic Server
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 Oracle WebLogic Server.
For more information about defining migratable services, see Service Migration in Using Clusters for Oracle WebLogic Server.
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 From an Unavailable Server in
Using Clusters for Oracle WebLogic Server.
Table 14–3 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 JTA for Oracle WebLogic Server.
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.
15
WebLogic JMS C API 15-1
15
WebLogic JMS C API
The following sections describe how to use the WebLogic JMS C API:
■
Section 15.1, What Is the WebLogic JMS C API?
