Configuring JMS Connection Recovery in the Event of Failure

Managing the RDBMS Security Store 10-7 For more information, see the following topics: ■ Configure topics in the Oracle WebLogic Server Administration Console Help ■ Configuring Basic JMS System Resources in Configuring and Managing JMS for Oracle WebLogic Server ■ Configure the RDBMS security store in the Oracle WebLogic Server Administration Console Help ■ RDBMSSecurityStoreMBean in the Oracle WebLogic Server MBean Reference

10.2.3.1 Configuring JMS Connection Recovery in the Event of Failure

Normally, the WebLogic Security Service contained in each WebLogic Server instance in a multi-node domain connects at startup to the JMS server. If a security provider that uses the RDBMS security store makes a change to its security data, all WebLogic Server instances are notified via JMS, and the local caches used by the WebLogic Security Service in each server instance are synchronized to that change. If the JMS connection fails in a WebLogic Server instance that has been successfully started, the WebLogic Security Service associated with that server instance starts the JMS connection recovery process. The recovery process sleeps one second between reconnect attempts. The recovery process is stopped if the JMS connection failure persists after the number of reconnect attempts with which the JMSExceptionReconnectAttempts property has been configured is reached. No further reconnect attempts are made: If a change is made to the security data in one WebLogic Server instance, the local caches managed by the WebLogic Security Service in other WebLogic Server instances are not synchronized to that change. However, if the JMS connection is successfully recovered by other means such as a server reboot, those caches become synchronized. If the JMS connection is not successfully started at the time a WebLogic Server instance is booted, a timer task that makes reconnect attempts is automatically started. The timer task is cancelled once the connection is successfully made. Two system properties may be configured for this timer task: ■ com.bea.common.security.jms.initialConnectionRecoverInterval Specifies the delay, in milliseconds, before the connection recovery task is executed. The default value is 1000, which causes the connection recovery process to be executed after a delay of one second. ■ com.bea.common.security.jms.initialConnectionRecoverAttempts Specifies the maximum number of reconnect attempts that can be made prior to cancelling the timer task. The default value is 3600, which causes the timer task to be cancelled once 3600 reconnect attempts have been made. No further reconnect attempts are made. JNDIUserName The identity of any valid user in the security realm who has access to JNDI. JNDIPassword The password of the user specified in the JNDIUserName attribute. JMSExceptionReconnectAttempts The number of reconnect attempts to be made if the JMS system notifies Kodo of a serious connection error. The default is 0, which causes an error to be logged, but does not result in a reconnect attempt. Table 10–2 Cont. RDBMSSecurityStoreMBean Attributes for Configuring a JMS Topic Attribute Name Description 10-8 Securing Oracle WebLogic Server You can calculate the maximum connection polling duration by multiplying the values specified by each of the preceding system properties. For example, multiplying the default values of these two properties yields a maximum polling duration of one hour 1000 millisecond delay multiplied by 3600 reconnect attempts.

10.3 Upgrading a Domain to Use the RDBMS Security Store

To upgrade a domain to use the RDBMS security store, Oracle recommends creating a new domain in which the RDBMS security store is configured. After you create the new domain, you should export the security data from the security realm of the old domain, and import it into a security realm of the new domain. When you import security data into a security realm in a domain that uses the RDBMS security store, the data for the security providers that use the RDBMS security store is automatically loaded into that datastore. Data for security providers that do not use the RDBMS security store is automatically imported into the stores that those providers normally use by default. It is possible to selectively migrate security providers individually from one security realm to another. However, when migrating security data to a domain that uses the RDBMS security store, Oracle recommends migrating the security realms data in a single operation. For information about migrating security realms, see the following topics: ■ Chapter 8, Migrating Security Data ■ Export data from security realms and Import data into security realms in the Oracle WebLogic Server Administration Console Help