Overview

This resource allows you to manage server tlog in an WebLogic domain.

Here is an example on how you should use this:

wls_server_tlog { 'JmsWlsServer1':
  ensure                 => 'present',
  tlog_datasource        => 'tlogDS',
  tlog_datasource_prefix => 'TLOG_JmsWlsServer1_',
  tlog_enabled           => 'true',
}

In this example you are managing a server tlog in the default domain. When you want to manage a server tlog in a specific domain, you can use:

wls_server_tlog { 'my_domain/WebServer1':
  ensure                 => 'present',
  tlog_datasource        => 'tlogDS',
  tlog_datasource_prefix => 'TLOG_WebServer1_',
  tlog_enabled           => 'true',
}

Attributes

Attribute Name Short Description
create_table_ddl_file Specifies the DDL (Data Definition Language) file to use for creating the JDBC store’s backing table.
data_source The JDBC data source used by this JDBC store to access its backing table.
deletes_per_batch_maximum The maximum number of table rows that are deleted per database call.
deletes_per_statement_maximum The maximum number of table rows that are deleted per database call.
deployment_order A priority that the server uses to determine when it deploys an item.
distribution_policy Specifies how the instances of a configured JMS artifact are named and distributed when deployed to a cluster.
domain With this parameter, you identify the domain, where your objects is in.
enabled When true, TLOGs are logged to a TLOG JDBC Store; otherwise, TLOGs are logged to the server’s default store.
ensure The basic property that the resource should be in.
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.
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.
inserts_per_batch_maximum The maximum number of table rows that are inserted per database call.
logical_name The name used by subsystems to refer to different stores on different servers using the same name.
max_retry_seconds_before_tlog_fail The maximum amount of time, in seconds, WebLogic Server tries to recover from a JDBC TLog store failure.
max_retry_seconds_before_tx_exception The maximum amount of time, in seconds, WebLogic Server waits before trying to recover from a JDBC TLog store failure while processing a transaction.
migration_policy Controls migration and restart behavior of cluster targeted JMS service artifact instances.
name The name.
notes Optional information that you can include to describe this configuration.
number_of_restart_attempts Specifies the number of restart attempts before migrating a failed JMS artifact instance to another server in the WebLogic cluster.
oracle_piggyback_commit_enabled Enables committing a batch of INSERT or DELETE operations with the last operation of the transaction instead of issuing a separate commit call to database server which saves a server round trip.
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 or On-Failure.
prefix_name When using multiple TLOG JDBC stores, use this attribute to create a label ending in “” that is prepended to the name of the server hosting the JDBC TLOG store and ends in “” to form a unique JDBC TLOG store name for each configured JDBC TLOG store.
provider resource.
reconnect_retry_interval_millis The length of time in milliseconds between reconnection attempts during the reconnection retry period.
reconnect_retry_period_millis Returns the length of time in milliseconds during which the persistent store will attempt to re-establish a connection to the database.
restart_in_place Enables periodic automatic restart of failed cluster targeted JMS artifact instance(s) running on healthy WebLogic Server instances.
retry_interval_seconds The amount of time, in seconds, WebLogic Server waits before attempting to verify the health of the TLOG store after a store failure has occurred.
seconds_between_restarts Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance.
server_name The server name
   
tags Return all tags on this Configuration MBean
   
three_step_threshold 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.
tlog_datasource The tlog datasource name
   
tlog_datasource_prefix The datasource prefix name for jdbc tlog
   
tlog_enabled Enables jdbc tlog functionality
   
worker_count The number of JDBC store worker threads to process the workerload.
worker_preferred_batch_size Specifies the batch size when the Worker Count attribute is configured to a value greater than 1.
xa_resource_name Overrides the name of the XAResource that this store registers with JTA.

create_table_ddl_file

Specifies the DDL (Data Definition Language) file to use for creating the JDBC store’s backing table. <ul> <li> This field is ignored when the JDBC store’s backing table, WLStore, already exists. </li> <li> 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 toreiojdbcddl directory of the MIDDLEWARE_HOMEmodulesm.bea.core.store.jdbc_x.x.x.x.jar file. </li> <li> 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. </li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   create_table_ddl_file => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:create_table_ddl_file']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

data_source

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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   data_source => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:data_source']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

deletes_per_batch_maximum

The maximum number of table rows that are deleted per database call. <ul> <li> When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests. </li> <li> Both the maximum batch size for concurrent inserts and for concurrent writes are configurable. </li> <li> To disable JDBC 3.0 batching, set the maximum batch size to 1. </li> <li> The maximum batch size has no effect on the maximum number of concurrent client requests. </li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   deletes_per_batch_maximum => '20'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:deletes_per_batch_maximum']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

deletes_per_statement_maximum

The maximum number of table rows that are deleted per database call. <ul> <li> Applies only when a JDBC store does not use JDBC 3.0 batching to batch concurrent client requests. </li> <li> The maximum deletes per statement has no effect on the maximum number of concurrent client requests. </li> <li> For some databases, the JDBC store may choose a lower value than the one configured. </li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   deletes_per_statement_maximum => '20'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:deletes_per_statement_maximum']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

deployment_order

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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   deployment_order => '1000'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:deployment_order']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

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: <ul> <li> 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. </li> <li> 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 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. </li> </ul> 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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   distribution_policy => 'Distributed'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:distribution_policy']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

domain

With this parameter, you identify the domain, where your objects is in.

The domain name is part of the full qualified name of any WebLogic object on a system. Let’s say we want to describe a WebLogic server. The full qualified name is:

wls_server{'domain_name/server_name':
  ensure => present,
  ...
}

When you don’t specify a domain name, Puppet will use default as domain name. For every domain you want to manage, you’ll have to put a wls_settings in your manifest.

Back to overview of wls_server_tlog

enabled

When true, TLOGs are logged to a TLOG JDBC Store; otherwise, TLOGs are logged to the server’s default store. When using the Administration Console, select JDBC to enable logging of TLOGs to a JDBC store; select Default Store to enable logging of TLOGs to the server’s default store.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   enabled => '1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:enabled']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 0, 1. Back to overview of wls_server_tlog

ensure

The basic property that the resource should be in.

Valid values are present, absent. Back to overview of wls_server_tlog

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. <ul> <li>A value > 0 specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.</li> <li>A value of 0 specifies there is no delay and the dynamic load balancer manages the failback process.</li> <li>A value of -1 specifies the default delay value is used.</li> </ul> Note: This setting only applies when the JMS artifact is cluster targeted and the Migration Policy is set to On-Failure or Always>.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   failback_delay_seconds => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:failback_delay_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

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. <ul> <li>A value > 0 is the time, in seconds, to delay before before loading resources after a failure and restart.</li> <li>A value of 0 specifies no delay.</li> <li>A value of -1 specifies the default delay value is used.</li> </ul> Note: This setting only applies when the JMS artifact is cluster targeted and the Migration Policy is set to On-Failure or Always>.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   initial_boot_delay_seconds => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:initial_boot_delay_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

inserts_per_batch_maximum

The maximum number of table rows that are inserted per database call. <ul> <li> When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests. </li> <li> Both the maximum batch size for concurrent inserts and for concurrent writes are configurable. </li> <li> To disable JDBC 3.0 batching, set the maximum batch size to 1. </li> <li> The maximum batch size has no effect on the maximum number of concurrent client requests. </li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   inserts_per_batch_maximum => '20'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:inserts_per_batch_maximum']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

logical_name

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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   logical_name => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:logical_name']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

max_retry_seconds_before_tlog_fail

The maximum amount of time, in seconds, WebLogic Server tries to recover from a JDBC TLog store failure. If store remains unusable after this period, WebLogic Server set the health state to HEALTH_FAILED. A value of 0 indicates WebLogic Server does not conduct a retry and and immediately sets the health state as HEALTH_FAILED.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   max_retry_seconds_before_tlog_fail => '300'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:max_retry_seconds_before_tlog_fail']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

max_retry_seconds_before_tx_exception

The maximum amount of time, in seconds, WebLogic Server waits before trying to recover from a JDBC TLog store failure while processing a transaction. If store remains unusable after this amount of time, WebLogic Server throws an exception the affected transaction. A value of 0 indicates WebLogic Server does not conduct a retry and an exception will thrown immediately. The practical maximum value is a value less than the current value of MaxRetrySecondsBeforeTLogFail.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   max_retry_seconds_before_tx_exception => '60'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:max_retry_seconds_before_tx_exception']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

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: <ul> <li>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. </li> <li>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. </li> <li>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. </li> </ul> Note: Cluster leasing must be configured for On-Failure and Always.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   migration_policy => 'Off'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:migration_policy']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

name

The name.

Back to overview of wls_server_tlog

notes

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 &lt;. Carriage returns/line feeds are preserved. <dl> <dt>Note:</dt> <dd> If you create or edit a note from the Administration Console, the Administration Console does not preserve carriage returns/line feeds. </dd> </dl>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   notes => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:notes']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

number_of_restart_attempts

Specifies the number of restart attempts before migrating a failed JMS artifact instance to another server in the WebLogic cluster. <ul> <li>A value > 0 specifies the number of restart attempts before migrating a failed service instance.</li> <li>A value of 0 specifies the same behavior as setting {@link #getRestartInPlace} to false.</li> <li>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.</li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   number_of_restart_attempts => '6'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:number_of_restart_attempts']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

oracle_piggyback_commit_enabled

Enables committing a batch of INSERT or DELETE operations with the last operation of the transaction instead of issuing a separate commit call to database server which saves a server round trip. This feature benefits applications that have many transactions of a small number of operations or small messages. This feature should be used only when configuring a JDBC store in Oracle Exalogic environments.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   oracle_piggyback_commit_enabled => '1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:oracle_piggyback_commit_enabled']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 0, 1. Back to overview of wls_server_tlog

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 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 once a cluster is fully started (stable) or when individual servers are started. <ul> <li>A value > 0 specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.</li> <li>A value of 0 specifies no delay.</li> <li>A value of -1 specifies a default delay value of 240 seconds.</li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   partial_cluster_stability_delay_seconds => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:partial_cluster_stability_delay_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

prefix_name

When using multiple TLOG JDBC stores, use this attribute to create a label ending in “” that is prepended to the name of the server hosting the JDBC TLOG store and ends in “” to form a unique JDBC TLOG store name for each configured JDBC TLOG store. The default prefix name is “TLOG_” . For example, a valid JDBC TLOG store name using the default Prefix Name is TLOG_MyServer_ where TLOG_ is the Prefix Name and MyServer is the name of the server hosting the JDBC TLOG store.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   prefix_name => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:prefix_name']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

provider

The specific backend to use for this wls_server_tlog resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.Available providers are:

simple
Manage tlog config on server in an WebLogic domain via regular WLST

Back to overview of wls_server_tlog

reconnect_retry_interval_millis

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

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   reconnect_retry_interval_millis => '200'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:reconnect_retry_interval_millis']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

reconnect_retry_period_millis

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

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   reconnect_retry_period_millis => '1000'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:reconnect_retry_period_millis']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

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. <ul> <li>Restarts occur when Restart In Place is set to true, the JMS artifact is cluster targeted, and the Migration Policy is set to On-Failure or Always>.</li> <li>This attribute is not used by WebLogic Messaging Bridges which automatically restart internal connections as needed. </li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   restart_in_place => '1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:restart_in_place']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 0, 1. Back to overview of wls_server_tlog

retry_interval_seconds

The amount of time, in seconds, WebLogic Server waits before attempting to verify the health of the TLOG store after a store failure has occurred.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   retry_interval_seconds => '5'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:retry_interval_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

seconds_between_restarts

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

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   seconds_between_restarts => '30'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:seconds_between_restarts']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

server_name

The server name

Back to overview of wls_server_tlog

tags

Return all tags on this Configuration MBean

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   tags => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:tags']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

three_step_threshold

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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   three_step_threshold => '200000'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:three_step_threshold']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

tlog_datasource

The tlog datasource name

Back to overview of wls_server_tlog

tlog_datasource_prefix

The datasource prefix name for jdbc tlog

Back to overview of wls_server_tlog

tlog_enabled

Enables jdbc tlog functionality

Valid values are absent, 0, 1. Back to overview of wls_server_tlog

worker_count

The number of JDBC store worker threads to process the workerload. <ul> <li>A value of 1 indicates a single thread is used (the default).</li> <li>A value greater than 1 indicates that multiple threads are used.</li> <li>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.</li> <li>For non-Oracle databases, refer to the database provider’s documentation for help with indexing.</li> </ul>

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   worker_count => '1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:worker_count']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

worker_preferred_batch_size

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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   worker_preferred_batch_size => '10'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:worker_preferred_batch_size']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog

xa_resource_name

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.

An example on how to use this:

wls_server_tlog {a_wls_server_tlog :
   ...
   xa_resource_name => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_server_tlog:xa_resource_name']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_server_tlog