Jump to

• Request
• Response

View This JDBC Store

get

/management/weblogic/{version}/domainConfig/JDBCStores/{name}

View this JDBC store.

Request

Path Parameters

• name: string
  The name property of the instance in the collection.
• version: string
  The version of the WebLogic REST interface.

Query Parameters

• excludeFields(optional): string
  The 'excludeFields' query parameter is used to restrict which fields are returned in the response. It is a comma separated list of field names. If present, only fields whose name is not on the list will be returned. If not present, all fields are returned (unless the 'fields' query parameter is specified). Note: 'fields' must not be specified if 'excludeFields' is specified.
• excludeLinks(optional): string
  The 'excludeLinks' query parameter is used to restrict which links are returned in the response. It is a comma separated list of link relationship names. If present, only links whose relationship name is not on the list will be returned. If not present, all links are returned (unless the 'links' query parameter is specified). Note: 'links' must not be specified if 'excludeLinks' is specified.
• fields(optional): string
  The 'fields' query parameter is used to restrict which fields are returned in the response. It is a comma separated list of field names. If present, only fields with matching names are returned. If not present, all fields are returned (unless the 'excludeFields' query parameter is specified). Note: 'excludeFields' must not be specified if 'fields' is specified.
• links(optional): string
  The 'links' query parameter is used to restrict which links are returned in the response. It is a comma separated list of link relationship names. If present, only links with matching relationship names are returned. If not present, all links are returned (unless the 'excludeLinks' query parameter is specified). Note: 'excludeLinks' must not be specified if 'links' is specified.

Security

• Admin: basic
  Type: basic

  Description: A user in the Admin security role.
• Deployer: basic
  Type: basic

  Description: A user in the Deployer security role.
• Monitor: basic
  Type: basic

  Description: A user in the Monitor security role.
• Operator: basic
  Type: basic

  Description: A user in the Operator security role.

Back to Top

Response

Supported Media Types

• application/json

200 Response

Returns this JDBC store.

This method can return the following links:

• rel=dataSource

  This resource's dataSource reference to a JDBC system resource resource.

Body ()

Root Schema : JDBC Store

Type: object

Show Source

• connectionCachingPolicy(optional): string
  Default Value: DEFAULT

  Allowed Values: [ "DEFAULT", "MINIMAL", "NONE" ]

  Advanced use only: gets the connection caching policy for the JDBC store.

  The return values will be one of:

  • JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_DEFAULT ("DEFAULT")

  • JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_MINIMAL ("MINIMAL")

  • JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_NONE ("NONE")

  IMPORTANT: See the below for additional usage information, particularly regarding NONE

  DEFAULT

  The default mode of operation for the JDBC store. The JDBC store will open two connections to the database and it will keep these connections open for the life of the store. In addition, if the worker count for the store is two or more, then it will open one connection for each of the workers and those connections will also stay open for the life of the JDBC store. If the worker count is 3 then the JDBC store will use 5 database connections. If the worker count is the default of 1 then the JDBC store will use just 2 connections.The DEFAULT setting is the recommended setting to be used when the database backing the JDBC store is not constrained with respect to the number of open connections.

  MINIMAL

  The JDBC store will open one connection to the database and it will keep that connection open for the life of the store. In addition, if the worker count for the store is two or more, then it will open one connection for each of the workers and those connections will also stay open for the life of the JDBC store. If the worker count is 3 then the JDBC store will use 4 database connections. If the worker count is the default of 1 then the JDBC store will use just 1 connection. The MINIMAL setting may result in a slight reduction of through-put for low concurrency messaging scenarios in comparison to DEFAULT.

  NONE

  The NONE connection caching policy is for 'advanced usage only'. The JDBC store will open one connection to the database on an as-needed basis to perform I/O and it will release that connection when the operation is complete. The NONE value is not compatible with a configured worker count of 2 or more and will result in a configuration validation exception. The NONE setting may result in a slight reduction of through-put for low concurrency messaging scenarios in comparison to DEFAULT or MINIMAL.

  NOTE: It is strongly recommended that a JDBC store be configured with a dedicated data source when the store is configured with the NONE connection caching policy. A store that shares a data source with other non-store components or applications runs the risk of failing due to dead-locks. Please note that a JDBC store will require more than one connection when first started. As such, a data source should be configured to grow and shrink so that the JDBC store can initialize.

• createTableDDLFile(optional): string
  Default Value: oracle.doceng.json.BetterJsonNull@1cc844e

  Specifies the DDL (Data Definition Language) file to use for creating the JDBC store's backing table.

  • This field is ignored when the JDBC store's backing table, WLStore, already exists.

  • If a DDL file is not specified and the JDBC store detects that a backing table doesn't already exist, the JDBC store automatically creates the table by executing a preconfigured DDL file that is specific to the database vendor. These preconfigured files are located in the weblogic\store\io\jdbc\ddl directory of the MIDDLEWARE_HOME\modules\com.bea.core.store.jdbc_x.x.x.x.jar file.

  • If a DDL file is specified and the JDBC store detects that a backing table doesn't already exist, then the JDBC store searches for the DDL file in the file path first, and then if the file is not found, it searches for it in the CLASSPATH. Once found, the SQL within the DDL file is executed to create the JDBC store's database table. If the DDL file is not found and the backing table doesn't already exist, the JDBC store will fail to boot.

• dataSource(optional): array JDBC System Resource Reference
  Title: JDBC System Resource Reference

  Contains the JDBC system resource reference.

  The JDBC data source used by this JDBC store to access its backing table.

  The specified data source must use a non-XA JDBC driver since connection pools for XA JDBC drivers are not supported.

  Constraints

  • restart required
• deletesPerBatchMaximum(optional): integer(int32)
  Minimum Value: 1

  Maximum Value: 100

  Default Value: 20

  The maximum number of table rows that are deleted per database call.

  • When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests.

  • Both the maximum batch size for concurrent inserts and for concurrent writes are configurable.

  • To disable JDBC 3.0 batching, set the maximum batch size to 1.

  • The maximum batch size has no effect on the maximum number of concurrent client requests.

• deletesPerStatementMaximum(optional): integer(int32)
  Minimum Value: 1

  Maximum Value: 100

  Default Value: 20

  The maximum number of table rows that are deleted per database call.

  • Applies only when a JDBC store does not use JDBC 3.0 batching to batch concurrent client requests.

  • The maximum deletes per statement has no effect on the maximum number of concurrent client requests.

  • For some databases, the JDBC store may choose a lower value than the one configured.

• deploymentOrder(optional): integer(int32)
  Minimum Value: 0

  Maximum Value: 2147483647

  Default Value: 1000

  A priority that the server uses to determine when it deploys an item. The priority is relative to other deployable items of the same type.

  For example, the server prioritizes and deploys all EJBs before it prioritizes and deploys startup classes.

  Items with the lowest Deployment Order value are deployed first. There is no guarantee on the order of deployments with equal Deployment Order values. There is no guarantee of ordering across clusters.

• distributionPolicy(optional): string
  Default Value: Distributed

  Allowed Values: [ "Distributed", "Singleton" ]

  Specifies how the instances of a configured JMS artifact are named and distributed when cluster-targeted. A JMS artifact is cluster-targeted when its target is directly set to a cluster, or when it is scoped to a resource group and the resource group is in turn targeted 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 instance on each server JVM in a cluster. Required for all SAF agents and for cluster-targeted or resource-group-scoped JMS servers that host distributed destinations.

  • Singleton Creates a single instance on a single server JVM within 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 be On-Failure or Always when using this option with a JMS server, On-Failure when using this option with a messaging bridge, and Always when using this option with a path service.

  Instance Naming Note:

  • The DistributionPolicy determines the instance name suffix for cluster-targeted JMS artifacts. The suffix for a cluster-targeted Singleton is -01 and for a cluster-targeted Distributed is @ClusterMemberName.

  Messaging Bridge Notes:

  • When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Distributed/Off, respectively; these are the defaults.

  • When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Singleton/On-Failure, respectively.

  • If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the Migration Policy on the migratable target to Exactly-Once.

• dynamicallyCreated(optional): boolean
  Read Only: true

  Default Value: false

  Return whether the MBean was created dynamically or is persisted to config.xml

• failbackDelaySeconds(optional): integer(int64)
  Default Value: -1

  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.

  • A value > specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.

  • A value of indicates that the instance would never failback.

  • A value of -1 indicates that there is no delay and the instance would failback immediately.

  Note: This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to On-Failure or Always

• failOverLimit(optional): integer(int32)
  Minimum Value: -1

  Default Value: -1

  Specify a limit for the number of cluster-targeted JMS artifact instances that can fail over to a particular JVM.

  This can be used to prevent too many instances from starting on a server, avoiding a system failure when starting too few servers of a formerly large cluster.

  A typical limit value should allow all instances to run in the smallest desired cluster size, which means (smallest-cluster-size * (limit + 1)) should equal or exceed the total number of instances.

  • A value of -1 means there is no fail over limit (unlimited).

  • A value of prevents any fail overs of cluster-targeted JMS artifact instances, so no more than 1 instance will run per server (this is an instance that has not failed over).

  • A value of allows one fail-over instance on each server, so no more than two instances will run per server (one failed over instance plus an instance that has not failed over).

  Note: This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to On-Failure or Always

• id(optional): integer(int64)
  Read Only: true

  Return the unique id of this MBean instance

• initialBootDelaySeconds(optional): integer(int64)
  Default Value: 60

  Specifies the amount of time, in seconds, to delay before starting a cluster-targeted JMS instance on a newly booted WebLogic Server instance. 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.

  • A value > is the time, in seconds, to delay before before loading resources after a failure and restart.

  • A value of specifies no delay.

  Note: This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to On-Failure or Always

• insertsPerBatchMaximum(optional): integer(int32)
  Minimum Value: 1

  Maximum Value: 100

  Default Value: 20

  The maximum number of table rows that are inserted per database call.

  • When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests.

  • Both the maximum batch size for concurrent inserts and for concurrent writes are configurable.

  • To disable JDBC 3.0 batching, set the maximum batch size to 1.

  • The maximum batch size has no effect on the maximum number of concurrent client requests.

• logicalName(optional): string
  Default Value: oracle.doceng.json.BetterJsonNull@1f125a18

  The name used by subsystems to refer to different stores on different servers using the same name.

  For example, an EJB that uses the timer service may refer to its store using the logical name, and this name may be valid on multiple servers in the same cluster, even if each server has a store with a different physical name.

  Multiple stores in the same domain or the same cluster may share the same logical name. However, a given logical name may not be assigned to more than one store on the same server.

  Constraints

  • legal null
• migrationPolicy(optional): string
  Default Value: Off

  Allowed Values: [ "Off", "On-Failure", "Always" ]

  Controls migration and restart behavior of cluster-targeted JMS service artifact instances. When this setting is configured on a cluster-targeted store, it applies to all JMS artifacts that reference the store. See the migratable target settings for enabling migration and restart on migratable-targeted JMS artifacts.

  • Off Disables migration support for cluster-targeted JMS service objects, and changes the default for Restart In Place to false. If you want a restart to be enabled when the Migration Policy is Off, then Restart In Place must be explicitly configured to true. This policy cannot 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.

  Note: Cluster leasing must be configured for On-Failure and Always.

  Messaging Bridge Notes:

  • When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Distributed/Off, respectively; these are the defaults.

  • When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Singleton/On-Failure, respectively.

  • A Migration Policy of Always is not recommended for bridges.

  • If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the Migration Policy on the migratable target to Exactly-Once.

• name(optional): string
  Read Only: true

  The user-specified name of this MBean instance.

  This name is included as one of the key properties in the MBean's javax.management.ObjectName

  Name=user-specified-name

  Constraints

  • legal null
• notes(optional): string

  Optional information that you can include to describe this configuration.

  WebLogic Server saves this note in the domain's configuration file (config.xml) as XML PCDATA. All left angle brackets (<) are converted to the xml entity <. Carriage returns/line feeds are preserved.

  Note: If you create or edit a note from the Administration Console, the Administration Console does not preserve carriage returns/line feeds.

• numberOfRestartAttempts(optional): integer(int32)
  Minimum Value: -1

  Default Value: 6

  Specifies the maximum number of restart attempts.

  • A value > specifies the maximum number of restart attempts.

  • A value of specifies the same behavior as setting getRestartInPlace to false

  • A value of -1 means infinite retry restart until it either starts or the server instance shuts down.

• partialClusterStabilityDelaySeconds(optional): integer(int64)
  Default Value: 240

  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 or On-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 after a cluster is fully started (stable) or when individual servers are started.

  • A value > specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.

  • A value of specifies no delay.

• prefixName(optional): string
  Default Value: oracle.doceng.json.BetterJsonNull@28f44609

  The prefix for the JDBC store's database table (WLStore), in the following format: [[[catalog.]schema.]prefix]

  Each period symbol in the [[catalog.]schema.]prefix format is significant, where schema generally corresponds to username in many databases. When no prefix is specified, the JDBC store table name is simply WLStore and the database implicitly determines the schema according to the JDBC connection's user. As a best practice, you should always configure a prefix for the JDBC WLStore table name.

  For specific guidelines about using JDBC store prefixes, refer to the "Using the WebLogic Store" section of Designing and Configuring WebLogic Server Environments"

• reconnectRetryIntervalMillis(optional): integer(int32)
  Minimum Value: 100

  Maximum Value: 10000

  Default Value: 200

  The length of time in milliseconds between reconnection attempts during the reconnection retry period.

  The reconnection interval applies to JDBC connections regardless of the database that is used for the JDBC store.

  The default value is 200 milliseconds

• reconnectRetryPeriodMillis(optional): integer(int32)
  Minimum Value: 200

  Maximum Value: 300000

  Default Value: 1000

  Returns the length of time in milliseconds during which the persistent store will attempt to re-establish a connection to the database. Successive reconnection attempts will be attempted after a fixed delay that is specified by the reconnection retry interval.

  The reconnection period applies to JDBC connections regardless of the database that is used for the JDBC store.

  The default value is 1000

• restartInPlace(optional): boolean

  Enables a periodic automatic in-place restart of failed cluster-targeted or standalone-server-targeted JMS artifact instance(s) running on healthy WebLogic Server instances. See the migratable target settings for in-place restarts of migratable-targeted JMS artifacts. When the Restart In Place setting is configured on a store, it applies to all JMS artifacts that reference the store.

  • If the Migration Policy of the JMS artifact is set to Off, Restart In Place is disabled by default.

  • If the Migration Policy of the JMS artifact is set to On-Failure or Always, Restart In Place is enabled by default.

  • This attribute is not used by WebLogic messaging bridges which automatically restart internal connections as needed.

  • For a JMS artifact that is cluster-targeted and the Migration Policy is set to On-Failure or Always, if restart fails after the configured maximum retry attempts, it will migrate to a different server within the cluster.

• secondsBetweenRestarts(optional): integer(int32)
  Minimum Value: 1

  Default Value: 30

  Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance.

• tags(optional): array Items
  Title: Items

  Return all tags on this Configuration MBean

• targets(optional): array Target References
  Title: Target References

  Contains the array of target references.

  The server instances, clusters, or migratable targets defined in the current domain that are candidates for hosting a file store, JDBC store, or replicated store. If scoped to a Resource Group or Resource Group Template, the target is inherited from the Virtual Target.

  When selecting a cluster, the store must be targeted to the same cluster as the JMS server. When selecting a migratable target, the store must be targeted it to the same migratable target as the migratable JMS server or SAF agent. As a best practice, a path service should use its own custom store and share the same target as the store.

• threeStepThreshold(optional): integer(int32)
  Minimum Value: 4000

  Maximum Value: 2147483647

  Default Value: 200000

  Specifies the threshold, in bytes, when the JDBC store uses 3 steps (insert, select, populate) instead of 1 step (insert) to populate an Oracle Blob data type.

  Applies only to Oracle databases where a Blob data type is used instead of the default Long Raw data type for record data.

  The default value is 200000.

• type(optional): string
  Read Only: true

  Returns the type of the MBean.

  Constraints

  • unharvestable
• workerCount(optional): integer(int32)
  Minimum Value: 1

  Maximum Value: 1000

  Default Value: 1

  The number of JDBC store worker threads to process the workerload.

  • A value of 1 indicates a single thread is used (the default).

  • A value greater than 1 indicates that multiple threads are used.

  • For Oracle databases, Oracle recommends users rebuild the primary key index into a reverse index for the JDBC Store table when the worker count is greater than 1.

  • For non-Oracle databases, refer to the database provider's documentation for help with indexing.

• workerPreferredBatchSize(optional): integer(int32)
  Minimum Value: 1

  Maximum Value: 2147483647

  Default Value: 10

  Specifies the batch size when the Worker Count attribute is configured to a value greater than 1.

  Used to configure the workload the JDBC store incrementally puts on each worker thread. The workload consists of IO requests which are grouped and pushed to each JDBC worker thread for processing. If the IO request is very large (for example 1M), then tune this attribute to a smaller value.

• XAResourceName(optional): string
  Read Only: true

  Default Value: oracle.doceng.json.BetterJsonNull@2b636fe6

  Overrides the name of the XAResource that this store registers with JTA.

  You should not normally set this attribute. Its purpose is to allow the name of the XAResource to be overridden when a store has been upgraded from an older release and the store contained prepared transactions. The generated name should be used in all other cases.

  Constraints

  • legal null

{
    "type":"object",
    "properties":{
        "XAResourceName":{
            "readOnly":true,
            "default":null,
            "x-weblogic-legalNull":true,
            "type":"string",
            "description":"<p>Overrides the name of the XAResource that this store registers with JTA.</p><p>You should not normally set this attribute. Its purpose is to allow the name of the XAResource to be overridden when a store has been upgraded from an older release and the store contained prepared transactions. The generated name should be used in all other cases.</p><p><h5>Constraints</h5></p><ul><li>legal null</li></ul>"
        },
        "connectionCachingPolicy":{
            "default":"DEFAULT",
            "enum":[
                "DEFAULT",
                "MINIMAL",
                "NONE"
            ],
            "type":"string",
            "description":"<p>Advanced use only: gets the connection caching policy for the JDBC store.</p><p>The return values will be one of:</p><ul><li><p>JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_DEFAULT (\"DEFAULT\")</p></li><li><p>JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_MINIMAL (\"MINIMAL\")</p></li><li><p>JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_NONE (\"NONE\")</p></li></ul><p>IMPORTANT: See the below for additional usage information, particularly regarding NONE</p><p>DEFAULT</p><p>The default mode of operation for the JDBC store.  The JDBC store will open two connections to the database and it will keep these connections open for the life of the store. In addition, if the worker count for the store is two or more, then it will open one connection for each of the workers and those connections will also stay open for the life of the JDBC store.  If the worker count is 3 then the JDBC store will use 5 database connections.  If the worker count is the default of 1 then the JDBC store will use just 2 connections.The DEFAULT setting is the recommended setting to be used when the database backing the JDBC store is not constrained with respect to the number of open connections.</p><p>MINIMAL</p><p>The JDBC store will open one connection to the database and it will keep that connection open for the life of the store. In addition, if the worker count for the store is two or more, then it will open one connection for each of the workers and those connections will also stay open for the life of the JDBC store. If the worker count is 3 then the JDBC store will use 4 database connections. If the worker count is the default of 1 then the JDBC store will use just 1 connection. The MINIMAL setting may result in a slight reduction of through-put for low concurrency messaging scenarios in comparison to DEFAULT.</p><p>NONE</p><p>The NONE connection caching policy is for 'advanced usage only'. The JDBC store will open one connection to the database on an as-needed basis to perform I/O and it will release that connection when the operation is complete. The NONE value is not compatible with a configured worker count of 2 or more and will result in a configuration validation exception. The NONE setting may result in a slight reduction of through-put for low concurrency messaging scenarios in comparison to DEFAULT or MINIMAL.</p><p>NOTE: It is strongly recommended that a JDBC store be configured with a dedicated data source when the store is configured with the NONE connection caching policy.  A store that shares a data source with other non-store components or applications runs the risk of failing due to dead-locks.  Please note that a JDBC store will require more than one connection when first started. As such, a data source should be configured to grow and shrink so that the JDBC store can initialize.</p>"
        },
        "createTableDDLFile":{
            "default":null,
            "type":"string",
            "description":"<p>Specifies the DDL (Data Definition Language) file to use for creating the JDBC store's backing table.</p><ul><li><p>This field is ignored when the JDBC store's backing table, <code>WLStore</code>, already exists.</p></li><li><p>If a DDL file is not specified and the JDBC store detects that a backing table doesn't already exist, the JDBC store automatically creates the table by executing a preconfigured DDL file that is specific to the database vendor. These preconfigured files are located in the  <code>weblogic\\store\\io\\jdbc\\ddl</code> directory of the <code><i>MIDDLEWARE_HOME</i>\\modules\\com.bea.core.store.jdbc_x.x.x.x.jar</code> file.</p></li><li><p>If a DDL file is specified and the JDBC store detects that a backing table doesn't already exist, then the JDBC store searches for the DDL file in the file path first, and then if the file is not found, it searches for it in the CLASSPATH. Once found, the SQL within the DDL file is executed to create the JDBC store's database table. If the DDL file is not found and the backing table doesn't already exist, the JDBC store will fail to boot.</p></li></ul>"
        },
        "dataSource":{
            "x-weblogic-restartRequired":true,
            "title":"JDBC System Resource Reference",
            "type":"array",
            "items":{
                "type":"string",
                "description":""
            },
            "description":"Contains the JDBC system resource reference. <p>The JDBC data source used by this JDBC store to access its backing table.</p><p>The specified data source must use a non-XA JDBC driver since connection pools for XA JDBC drivers are not supported.</p><p><h5>Constraints</h5></p><ul><li>restart required</li></ul>"
        },
        "deletesPerBatchMaximum":{
            "default":20,
            "minimum":1,
            "maximum":100,
            "type":"integer",
            "format":"int32",
            "description":"<p>The maximum number of table rows that are deleted per database call.</p><ul><li><p> When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests. </p></li><li><p> Both the maximum batch size for concurrent inserts and for concurrent writes are configurable. </p></li><li><p> To disable JDBC 3.0 batching, set the maximum batch size to 1. </p></li><li><p> The maximum batch size has no effect on the maximum number of concurrent client requests. </p></li></ul>"
        },
        "deletesPerStatementMaximum":{
            "default":20,
            "minimum":1,
            "maximum":100,
            "type":"integer",
            "format":"int32",
            "description":"<p>The maximum number of table rows that are deleted per database call.</p><ul><li><p> Applies only when a JDBC store does not use JDBC 3.0 batching to batch concurrent client requests. </p></li><li><p> The maximum deletes per statement has no effect on the maximum number of concurrent client requests. </p></li><li><p> For some databases, the JDBC store may choose a lower value than the one configured. </p></li></ul>"
        },
        "deploymentOrder":{
            "default":1000,
            "minimum":0,
            "maximum":2147483647,
            "type":"integer",
            "format":"int32",
            "description":"<p>A priority that the server uses to determine when it deploys an item. The priority is relative to other deployable items of the same type.</p><p>For example, the server prioritizes and deploys all EJBs before it prioritizes and deploys startup classes.</p><p>Items with the lowest Deployment Order value are deployed first. There is no guarantee on the order of deployments with equal Deployment Order values. There is no guarantee of ordering across clusters.</p>"
        },
        "distributionPolicy":{
            "default":"Distributed",
            "enum":[
                "Distributed",
                "Singleton"
            ],
            "type":"string",
            "description":"<p>Specifies how the instances of a configured JMS artifact are named and distributed when cluster-targeted.  A JMS artifact is cluster-targeted when its target is directly set to a cluster, or when it is scoped to a resource group and the resource group is in turn targeted to a cluster.  When this setting is configured on a store, it applies to all JMS artifacts that reference the store.  Valid options:</p><ul><li><p><code>Distributed</code> Creates an instance on each server JVM in a cluster. Required for all SAF agents and for cluster-targeted or resource-group-scoped JMS servers that host distributed destinations. </p></li><li><p><code>Singleton</code> Creates a single instance on a single server JVM within 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 <code>Migration Policy</code> must be <code>On-Failure</code> or <code>Always</code> when using this option with a JMS server, <code>On-Failure</code> when using this option with a messaging bridge, and <code>Always</code> when using this option with a path service. </p></li></ul><p><b>Instance Naming Note:</b></p><ul><li><p> The <code>DistributionPolicy</code> determines the instance name suffix for cluster-targeted JMS artifacts.  The suffix for a cluster-targeted <code>Singleton</code> is <code>-01</code> and for a cluster-targeted <code>Distributed</code> is <code>@ClusterMemberName</code>. </p></li></ul><p><b>Messaging Bridge Notes:</b></p><ul><li><p> When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Distributed/Off</code>, respectively; these are the defaults. </p></li><li><p> When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Singleton/On-Failure</code>, respectively. </p></li><li><p> If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the <code>Migration Policy</code> on the migratable target to <code>Exactly-Once</code>. </p></li></ul>"
        },
        "dynamicallyCreated":{
            "readOnly":true,
            "default":false,
            "type":"boolean",
            "description":"<p>Return whether the MBean was created dynamically or is persisted to config.xml</p>"
        },
        "failOverLimit":{
            "default":-1,
            "minimum":-1,
            "type":"integer",
            "format":"int32",
            "description":"<p>Specify a limit for the number of cluster-targeted JMS artifact instances that can fail over to a particular JVM.</p><p>This can be used to prevent too many instances from starting on a server, avoiding a system failure when starting too few servers of a formerly large cluster.</p><p>A typical limit value should allow all instances to run in the smallest desired cluster size, which means (smallest-cluster-size * (limit + 1)) should equal or exceed the total number of instances. </p><ul><li><p>A value of <code>-1</code> means there is no fail over limit (unlimited).</p></li><li><p>A value of <code></code> prevents any fail overs of cluster-targeted JMS artifact instances, so no more than 1 instance will run per server (this is an instance that has not failed over).</p></li><li><p>A value of <code></code> allows one fail-over instance on each server, so no more than two instances will run per server (one failed over instance plus an instance that has not failed over).</p></li></ul><p><b>Note:</b> This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code></p>"
        },
        "failbackDelaySeconds":{
            "default":-1,
            "type":"integer",
            "format":"int64",
            "description":"<p>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.</p><p>This delay allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot.</p><ul><li><p>A value > <code></code> specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.</p></li><li><p>A value of <code></code> indicates that the instance would never failback.</p></li><li><p>A value of <code>-1</code> indicates that there is no delay and the instance would failback immediately.</p></li></ul><p><b>Note:</b> This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code></p>"
        },
        "id":{
            "readOnly":true,
            "type":"integer",
            "format":"int64",
            "description":"<p>Return the unique id of this MBean instance</p>"
        },
        "initialBootDelaySeconds":{
            "default":60,
            "type":"integer",
            "format":"int64",
            "description":"<p>Specifies the amount of time, in seconds, to delay before starting a cluster-targeted JMS instance on a newly booted WebLogic Server instance. When this setting is configured on a store, it applies to all JMS artifacts that reference the store. </p><p>This allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot.</p><ul><li><p>A value > <code></code> is the time, in seconds, to delay before before loading resources after a failure and restart.</p></li><li><p>A value of <code></code> specifies no delay.</p></li></ul><p><b>Note:</b> This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code></p>"
        },
        "insertsPerBatchMaximum":{
            "default":20,
            "minimum":1,
            "maximum":100,
            "type":"integer",
            "format":"int32",
            "description":"<p>The maximum number of table rows that are inserted per database call.</p><ul><li><p> When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests. </p></li><li><p> Both the maximum batch size for concurrent inserts and for concurrent writes are configurable. </p></li><li><p> To disable JDBC 3.0 batching, set the maximum batch size to 1. </p></li><li><p> The maximum batch size has no effect on the maximum number of concurrent client requests. </p></li></ul>"
        },
        "logicalName":{
            "default":null,
            "x-weblogic-legalNull":true,
            "type":"string",
            "description":"<p>The name used by subsystems to refer to different stores on different servers using the same name.</p><p>For example, an EJB that uses the timer service may refer to its store using the logical name, and this name may be valid on multiple servers in the same cluster, even if each server has a store with a different physical name.</p><p>Multiple stores in the same domain or the same cluster may share the same logical name. However, a given logical name may not be assigned to more than one store on the same server.</p><p><h5>Constraints</h5></p><ul><li>legal null</li></ul>"
        },
        "migrationPolicy":{
            "default":"Off",
            "enum":[
                "Off",
                "On-Failure",
                "Always"
            ],
            "type":"string",
            "description":"<p>Controls migration and restart behavior of cluster-targeted JMS service artifact instances. When this setting is configured on a cluster-targeted store, it applies to all JMS artifacts that reference the store. See the migratable target settings for enabling migration and restart on migratable-targeted JMS artifacts.</p><ul><li><p><code>Off</code> Disables migration support for cluster-targeted JMS service objects, and changes the default for Restart In Place to false. If you want a restart to be enabled when the Migration Policy is Off, then Restart In Place must be explicitly configured to true. This policy cannot be combined with the <code>Singleton</code> Migration Policy. </p></li><li><p><code>On-Failure</code> 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. </p></li><li><p><code>Always</code> Provides the same behavior as <code>On-Failure</code> and automatically migrates instances even in the event of a graceful shutdown or a partial cluster start. </p></li></ul><p><b>Note:</b> Cluster leasing must be configured for <code>On-Failure</code> and <code>Always</code>.  </p><p><b>Messaging Bridge Notes:</b></p><ul><li><p> When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Distributed/Off</code>, respectively; these are the defaults. </p></li><li><p> When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Singleton/On-Failure</code>, respectively. </p></li><li><p> A <code>Migration Policy</code> of <code>Always</code> is not recommended for bridges. </p></li><li><p> If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the <code>Migration Policy</code> on the migratable target to <code>Exactly-Once</code>. </p></li></ul>"
        },
        "name":{
            "readOnly":true,
            "x-weblogic-legalNull":true,
            "type":"string",
            "description":"<p>The user-specified name of this MBean instance.</p><p>This name is included as one of the key properties in the MBean's <code>javax.management.ObjectName</code></p><p><code>Name=<i>user-specified-name</i></code></p><p><h5>Constraints</h5></p><ul><li>legal null</li></ul>"
        },
        "notes":{
            "type":"string",
            "description":"<p>Optional information that you can include to describe this configuration.</p><p>WebLogic Server saves this note in the domain's configuration file (<code>config.xml</code>) as XML PCDATA. All left angle brackets (<) are converted to the XML entity <code>&lt;</code>. Carriage returns/line feeds are preserved.</p><p>Note: If you create or edit a note from the Administration Console, the Administration Console does not preserve carriage returns/line feeds.</p>"
        },
        "numberOfRestartAttempts":{
            "default":6,
            "minimum":-1,
            "type":"integer",
            "format":"int32",
            "description":"<p>Specifies the maximum number of restart attempts.</p><ul><li><p>A value > <code></code> specifies the maximum number of restart attempts.</p></li><li><p>A value of <code></code> specifies the same behavior as setting getRestartInPlace to <code>false</code></p></li><li><p>A value of <code>-1</code> means infinite retry restart until it either starts or the server instance shuts down.</p></li></ul>"
        },
        "partialClusterStabilityDelaySeconds":{
            "default":240,
            "type":"integer",
            "format":"int64",
            "description":"<p>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 <code>Always</code> or <code>On-Failure</code>. </p><p>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.</p><p>This delay ensures that services are balanced across a cluster even if the servers are started sequentially. It is ignored after a cluster is fully started (stable) or when individual servers are started.</p><ul><li><p>A value > <code></code> specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.</p></li><li><p>A value of <code></code> specifies no delay.</p></li></ul>"
        },
        "prefixName":{
            "default":null,
            "type":"string",
            "description":"<p>The prefix for the JDBC store's database table (<code>WLStore</code>), in the following format: <code>[[[catalog.]schema.]prefix]</code></p><p>Each period symbol in the <code>[[catalog.]schema.]prefix</code> format is significant, where schema generally corresponds to username in many databases. When no prefix is specified, the JDBC store table name is simply <code>WLStore</code> and the database implicitly determines the schema according to the JDBC connection's user. As a best practice, you should always configure a prefix for the JDBC <code>WLStore</code> table name.</p><p> For specific guidelines about using JDBC store prefixes, refer to the \"Using the WebLogic Store\" section of <i>Designing and Configuring WebLogic Server Environments\"</i></p>"
        },
        "reconnectRetryIntervalMillis":{
            "default":200,
            "minimum":100,
            "maximum":10000,
            "type":"integer",
            "format":"int32",
            "description":"<p>The length of time in milliseconds between reconnection attempts during the reconnection retry period.</p><p>The reconnection interval applies to JDBC connections regardless of the database that is used for the JDBC store.</p><p>The default value is 200 milliseconds</p>"
        },
        "reconnectRetryPeriodMillis":{
            "default":1000,
            "minimum":200,
            "maximum":300000,
            "type":"integer",
            "format":"int32",
            "description":"<p>Returns the length of time in milliseconds during which the persistent store will attempt to re-establish a connection to the database.  Successive reconnection attempts will be attempted after a fixed delay that is specified by the reconnection retry interval.</p><p>The reconnection period applies to JDBC connections regardless of the database that is used for the JDBC store.</p><p>The default value is 1000</p>"
        },
        "restartInPlace":{
            "type":"boolean",
            "description":"<p> Enables a periodic automatic in-place restart of failed cluster-targeted or standalone-server-targeted JMS artifact instance(s) running on healthy WebLogic Server instances. See the migratable target settings for in-place restarts of migratable-targeted JMS artifacts. When the Restart In Place setting is configured on a store, it applies to all JMS artifacts that reference the store.</p><ul><li><p>If the Migration Policy of the JMS artifact is set to <code>Off</code>, Restart In Place is disabled by default.</p></li><li><p>If the Migration Policy of the JMS artifact is set to <code>On-Failure</code> or <code>Always</code>, Restart In Place is enabled by default.</p></li><li><p>This attribute is not used by WebLogic messaging bridges which automatically restart internal connections as needed.</p></li><li><p>For a JMS artifact that is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code>, if restart fails after the configured maximum retry attempts, it will migrate to a different server within the cluster. </p></li></ul>"
        },
        "secondsBetweenRestarts":{
            "default":30,
            "minimum":1,
            "type":"integer",
            "format":"int32",
            "description":"<p>Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance.</p>"
        },
        "tags":{
            "title":"Items",
            "type":"array",
            "items":{
                "type":"string",
                "description":""
            },
            "description":"<p>Return all tags on this Configuration MBean</p>"
        },
        "targets":{
            "title":"Target References",
            "type":"array",
            "items":{
                "title":"Target Reference",
                "type":"object",
                "properties":{
                    "identity":{
                        "title":"Identity",
                        "type":"array",
                        "items":{
                            "type":"string",
                            "description":""
                        },
                        "description":"DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource."
                    }
                },
                "description":"Contains the target reference."
            },
            "description":"Contains the array of target references. <p>The server instances, clusters, or migratable targets defined in the current domain that are candidates for hosting a file store, JDBC store, or replicated store. If scoped to a Resource Group or Resource Group Template, the target is inherited from the Virtual Target.</p><p>When selecting a cluster, the store must be targeted to the same cluster as the JMS server. When selecting a migratable target, the store must be targeted it to the same migratable target as the migratable JMS server or SAF agent. As a best practice, a path service should use its own custom store and share the same target as the store.</p>"
        },
        "threeStepThreshold":{
            "default":200000,
            "minimum":4000,
            "maximum":2147483647,
            "type":"integer",
            "format":"int32",
            "description":"<p>Specifies the threshold, in bytes, when the JDBC store uses 3 steps (insert, select, populate) instead of 1 step (insert) to populate an Oracle Blob data type. </p><p>Applies only to Oracle databases where a Blob data type is used instead of the default Long Raw data type for record data. </p><p>The default value is 200000.</p>"
        },
        "type":{
            "readOnly":true,
            "x-weblogic-unharvestable":true,
            "type":"string",
            "description":"<p>Returns the type of the MBean.</p><p><h5>Constraints</h5></p><ul><li>unharvestable</li></ul>"
        },
        "workerCount":{
            "default":1,
            "minimum":1,
            "maximum":1000,
            "type":"integer",
            "format":"int32",
            "description":"<p>The number of JDBC store worker threads to process the workerload.</p><ul><li><p>A value of 1 indicates a single thread is used (the default).</p></li><li><p>A value greater than 1 indicates that multiple threads are used.</p></li><li><p>For Oracle databases, Oracle recommends users rebuild the primary key index into a reverse index for the JDBC Store table when the worker count is greater than 1.</p></li><li><p>For non-Oracle databases, refer to the database provider's documentation for help with indexing.</p></li></ul>"
        },
        "workerPreferredBatchSize":{
            "default":10,
            "minimum":1,
            "maximum":2147483647,
            "type":"integer",
            "format":"int32",
            "description":"<p>Specifies the batch size when the <code>Worker Count</code> attribute is configured to a value greater than 1.</p><p>Used to configure the workload the JDBC store incrementally puts on each worker thread. The workload consists of IO requests which are grouped and pushed to each JDBC worker thread for processing. If the IO request is very large (for example 1M), then tune this attribute to a smaller value.</p>"
        }
    },
    "description":""
}

Nested Schema : JDBC System Resource Reference

Type: array

Title: JDBC System Resource Reference

Contains the JDBC system resource reference.

The JDBC data source used by this JDBC store to access its backing table.

The specified data source must use a non-XA JDBC driver since connection pools for XA JDBC drivers are not supported.

Constraints

• restart required

Show Source

• Array of: string

{
    "x-weblogic-restartRequired":true,
    "title":"JDBC System Resource Reference",
    "type":"array",
    "items":{
        "type":"string",
        "description":""
    },
    "description":"Contains the JDBC system resource reference. <p>The JDBC data source used by this JDBC store to access its backing table.</p><p>The specified data source must use a non-XA JDBC driver since connection pools for XA JDBC drivers are not supported.</p><p><h5>Constraints</h5></p><ul><li>restart required</li></ul>"
}

Nested Schema : Items

Type: array

Title: Items

Return all tags on this Configuration MBean

Show Source

• Array of: string

{
    "title":"Items",
    "type":"array",
    "items":{
        "type":"string",
        "description":""
    },
    "description":"<p>Return all tags on this Configuration MBean</p>"
}

Nested Schema : Target References

Type: array

Title: Target References

Contains the array of target references.

The server instances, clusters, or migratable targets defined in the current domain that are candidates for hosting a file store, JDBC store, or replicated store. If scoped to a Resource Group or Resource Group Template, the target is inherited from the Virtual Target.

When selecting a cluster, the store must be targeted to the same cluster as the JMS server. When selecting a migratable target, the store must be targeted it to the same migratable target as the migratable JMS server or SAF agent. As a best practice, a path service should use its own custom store and share the same target as the store.

Show Source

• Array of: object Target Reference
  Title: Target Reference

  Contains the target reference.

{
    "title":"Target References",
    "type":"array",
    "items":{
        "title":"Target Reference",
        "type":"object",
        "properties":{
            "identity":{
                "title":"Identity",
                "type":"array",
                "items":{
                    "type":"string",
                    "description":""
                },
                "description":"DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource."
            }
        },
        "description":"Contains the target reference."
    },
    "description":"Contains the array of target references. <p>The server instances, clusters, or migratable targets defined in the current domain that are candidates for hosting a file store, JDBC store, or replicated store. If scoped to a Resource Group or Resource Group Template, the target is inherited from the Virtual Target.</p><p>When selecting a cluster, the store must be targeted to the same cluster as the JMS server. When selecting a migratable target, the store must be targeted it to the same migratable target as the migratable JMS server or SAF agent. As a best practice, a path service should use its own custom store and share the same target as the store.</p>"
}

Nested Schema : Target Reference

Type: object

Title: Target Reference

Contains the target reference.

Show Source

• identity(optional): array Identity
  Title: Identity

  DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource.

{
    "title":"Target Reference",
    "type":"object",
    "properties":{
        "identity":{
            "title":"Identity",
            "type":"array",
            "items":{
                "type":"string",
                "description":""
            },
            "description":"DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource."
        }
    },
    "description":"Contains the target reference."
}

Nested Schema : Identity

Type: array

Title: Identity

DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource.

Show Source

• Array of: string

{
    "title":"Identity",
    "type":"array",
    "items":{
        "type":"string",
        "description":""
    },
    "description":"DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource."
}

Back to Top