Programming WebLogic JMS
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.
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.
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.