JDBC Store: HA Configuration
Configuration Options Related Tasks Related Topics
Use this page to configure HA settings for a cluster targeted JDBC Store
Configuration Options
Name Description Distribution Policy Specifies how the instances of a configured JMS artifact are named and distributed when deployed to a cluster. When this setting is configured on a Store it applies to all JMS artifacts that reference the store. Valid options:
Distributed
creates an artifact instance on each cluster member in a cluster. Required for all SAF Agents and for cluster targeted or resource group scoped JMS Servers that host distributed destinations.
Singleton
creates one artifact instance on a single cluster member of a cluster. Required for cluster targeted or resource group scoped JMS Servers that host standalone (non-distributed) destinations and for cluster targeted or resource group scoped Path Services. The
Migration Policy
must beOn-Failure
orAlways
when using this option with a JMS Server,On-Failure
when using this option with a Messaging Bridge, andAlways
when using this option with a Path Service.The
DistributionPolicy
determines the instance name suffix for cluster targeted JMS artifacts. The suffix for a cluster targetedSingleton
is-01
and for a cluster targetedDistributed
is@ClusterMemberName
.MBean Attribute:
DynamicDeploymentMBean.DistributionPolicy
Changes take effect after you redeploy the module or restart the server.
Migration Policy Controls migration and restart behavior of cluster targeted JMS service artifact instances. When this setting is configured on a Store it applies to all JMS artifacts that reference the store. Valid options:
Note:
Off
disables migration and restart support for cluster targeted JMS service objects, including the ability to restart a failed persistent store instance and its associated services. This policy can not be combined with the
Singleton
Migration Policy.On-Failure
enables automatic migration and restart of instances on the failure of a subsystem Service or WebLogic Server instance, including automatic fail-back and load balancing of instances.
Always
provides the same behavior as
On-Failure
and automatically migrates instances even in the event of a graceful shutdown or a partial cluster start.Cluster leasing must be configured for
On-Failure
andAlways
.MBean Attribute:
DynamicDeploymentMBean.MigrationPolicy
Changes take effect after you redeploy the module or restart the server.
Restart In Place Enables periodic automatic restart of failed cluster targeted JMS artifact instance(s) running on healthy WebLogic Server instances. Restart attempts occur before attempts to migrate an instance to a different server in the cluster. When this setting is configured on a Store it applies to all JMS artifacts that reference the store.
Restarts occur when Restart In Place is set to
true
, the JMS artifact is cluster targeted, and the Migration Policy is set toOn-Failure
orAlways>
.This attribute is not used by WebLogic Messaging Bridges which automatically restart internal connections as needed.
MBean Attribute:
DynamicDeploymentMBean.RestartInPlace
Changes take effect after you redeploy the module or restart the server.
Seconds Between Restarts Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance.
MBean Attribute:
DynamicDeploymentMBean.SecondsBetweenRestarts
Changes take effect after you redeploy the module or restart the server.
Number Of Restart Attempts Specifies the number of restart attempts before migrating a failed JMS artifact instance to another server in the WebLogic cluster.
A value >
0
specifies the number of restart attempts before migrating a failed service instance.A value of
0
specifies the same behavior as setting RestartInPlace tofalse
.A value of
-1
specifies the service is never migrated. Instead, it continues to attempt to restart until it either starts or the server instance shuts down.MBean Attribute:
DynamicDeploymentMBean.NumberOfRestartAttempts
Changes take effect after you redeploy the module or restart the server.
Initial Boot Delay Seconds Specifies the amount of time, in seconds, to delay before starting a cluster targeted JMS instance on a newly booted WebLogic server. When this setting is configured on a Store it applies to all JMS artifacts that reference the store.
This allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot.
Note:
A value >
0
is the time, in seconds, to delay before before loading resources after a failure and restart.A value of
0
specifies no delay.A value of
-1
specifies the default delay value is used.This setting only applies when the JMS artifact is cluster targeted and the Migration Policy is set to
On-Failure
orAlways>
.MBean Attribute:
DynamicDeploymentMBean.InitialBootDelaySeconds
Changes take effect after you redeploy the module or restart the server.
Failback Delay Seconds Specifies the amount of time, in seconds, to delay before failing a cluster targeted JMS artifact instance back to its preferred server after the preferred server failed and was restarted.
This delay allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot.
Note:
A value >
0
specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.A value of
0
specifies there is no delay and the dynamic load balancer manages the failback process.A value of
-1
specifies the default delay value is used.This setting only applies when the JMS artifact is cluster targeted and the Migration Policy is set to
On-Failure
orAlways>
.MBean Attribute:
DynamicDeploymentMBean.FailbackDelaySeconds
Changes take effect after you redeploy the module or restart the server.
Partial Cluster Stability Delay Seconds Specifies the amount of time, in seconds, to delay before a partially started cluster starts all cluster targeted JMS artifact instances that are configured with a Migration Policy of
Always
orOn-Failure
.Before this timeout expires or all servers are running, a cluster starts a subset of such instances based on the total number of servers running and the configured cluster size. Once the timeout expires or all servers have started, the system considers the cluster stable and starts any remaining services.
This delay ensures that services are balanced across a cluster even if the servers are started sequentially. It is ignored once a cluster is fully started (stable) or when individual servers are started.
A value >
0
specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.A value of
0
specifies no delay.A value of
-1
specifies a default delay value of 240 seconds.MBean Attribute:
PersistentStoreMBean.PartialClusterStabilityDelaySeconds
Changes take effect after you redeploy the module or restart the server.