CDD Cluster Tab Backing Store Properties Reference

Use this reference for the backing store properties.

For the related procedure, see Configuring Backing Store Settings and Properties.

CDD Cluster Tab Backing Store Properties
Property Notes
Database Connection Properties

Used only if Enforce Pools is checked (see CDD Cluster Tab Backing Store Settings Reference ).

be.backingstore.dburi.pool.waitTimeout.0
  Used only if the Strategy setting (see CDD Cluster Tab Backing Store Settings Reference ) is set to oracle.
Oracle Database Strategy
If the Cluster tab > Backing Store > Strategy field is set to oracle, then Oracle Database strategy settings are used, and this property corresponds to the OracleConnectionCacheManager class property WaitTimeout.

Specifies behavior when a connection is requested and there are already Cluster tab > Backing Store > Connection > Max Size connections active. If the be.backingstore.dburi.pool.waitTimeout.0 value is greater than zero (0), each connection request waits for up to the specified number of seconds. If no connection is returned to the pool before the timeout elapses, a No Database Connection available exception is thrown.

The waitTimeout and inactivityTimeout properties specify wait periods to minimize the creation and destruction of connections (an expensive operation).

Default is 1 second.

be.backingstore.dburi.pool.inactivityTimeout.0
 
Oracle Database Strategy
If the Cluster tab > Backing Store > Strategy field is set to oracle, then Oracle Database strategy settings are used, and this property corresponds to the OracleConnectionCacheManager class property InactivityTimeout.

Specifies the number of seconds an unused connection remains available (so that other threads can use it). After this period, the connection is closed and removed from the pool.

Default value is 900 seconds.

be.backingstore.readtimeout
 
Oracle Database Strategy
If the Cluster tab > Backing Store > Strategy field is set to oracle, then Oracle Database strategy settings are used, and this property corresponds to the OracleConnectionCacheManager class property ReadTimeout.

Use this property to handle situations where engines running inference agents hang when the JDBC connection to the backing store is slow or intermittent. If no response is received from the database within the specified period, a call is aborted.

Time unit is milliseconds.

A value of 0 (zero) means that no timeout is set.

Default value is 0 .

be.backingstore.recreateOnRecovery
  Set this property to true if the database pool size does not recover to the initial or minimum connection size, as defined by Min Size and Max Size properties (in CDD Cluster Tab Backing Store Settings Reference ).

Default value is false.

Other properties
be.backingstore.useobjecttable
The property when set to true provides mappings for all entities in the cache. Object table is used to find the actual object either in the cache or in the backing store.

When this property is set to false, you must use the catalog functions with the "byURI()" pattern so that entities are found from the cache.

Default value is true.

be.backingstore.commitSize
  Used with the Coherence cache provider and write-behind strategy only.

Sets the maximum number of RTC transactions that a distributed cache service thread takes from the distributed cache service queue and processes in one batch. When threads are idle, they take jobs from the queue in smaller batches.

Set this property to the desired number of transactions to suit your needs.

Refer to the "Write Behind Options" section in the TIBCO BusinessEvents Architect’s Guide for more details.

Default value is 10.

be.backingstore.optimize.reads
  Used with Microsoft SQL Server only.

Set the property to true to improve the runtime performance.

Use NOLOCK for SELECT statements to avoid locks on the database or table when SELECT statements are issued. An example syntax is:

select * from dbo.D_MailerIndex with (nolock) where ...
be.backingstore.optimize.writes
  Used with Microsoft SQL Server only.

Set the property to true to improve the runtime performance.

Use ROWLOCK with UPDATE or DELETE statements to avoid lock contentions. When you use ROWLOCK in the T-SQL statement, the SQL Server locks only the rows that match the ’where’ condition and not the entire table. An example syntax is:

DELETE FROM dbo.D_Mailed WITH (ROWLOCK) where mailernumber = '12345678895' and time_created$ = 'somedate'
be.backingstore.timestamp.useDataTimeZone
  Used when the backing store is enabled.

Set the property to true to ensure that the correct DateTime properties are retrieved when an agent’s time zone is changed and the agent is restarted.

be.engine.cluster.cleanup
  Used with write-behind strategy only. By default, deleted entities are removed from the backing store automatically at system startup. Set this property to false to disable that behavior.

Default is true.

be.engine.cluster.recovery.threads
  Recovery threads are used when pre-loading the cache during startup.

For an explanation of pre-loading and other pre-loading controls, see At system startup, domain object settings will determine how entity objects are stored and pre-loaded from the backing store to cache.. .

Default is 5.

be.engine.cluster.recovery.distributed.strategy 
This property is used for Shared All and for Shared Nothing persistence.
  • For Shared All: Possible values for this property are batch and nobatch.

    Batch mode is a distributed batch mode, where one cache node is the 'director' and gives jobs to other nodes while recovering data from the backing store. Therefore, more than one node is needed. All nodes need to be started at once so jobs gets distributed evenly. While in nobatch mode, each node tries to pick up a job by itself while recovering data from the backing store.

    Default is nobatch.

    Note: By using the JMX Mbeans > Pre-load and Recovery Information, you can view which seeders are performing recovery depending on the strategy mentioned in CDD as either Batch and NoBatch in the JConsole.
  • For Shared nothing: The be.engine.cluster.recovery.distributed.strategy parameter has the five following recovery policies added as part of the recovery options. When shared nothing persistence is implemented and recovery is issued, then the policy determines when and how recovery can be made. The following are the allowed values for the five recovery policies:

    • The no_data recovers the space without any data. This is same as removing shared nothing persistence files.

    • The data_loss recovers the space with available data from each seeder. If recovery is done with missing seeders, there is a potential for data loss, because not all members are started, to ensure that all data is recovered. This policy ensures best-effort recovery with the available data.

    • The no_data_loss recovers the space only if there are enough members to be able to recover the data before shutdown. If enough seeders are not available to recover the previous state of the cluster, recovery throws an exception.

    • The fast_load_only recovers the space only if all of the members that were active before the shutdown is available in the cluster. This policy enables fast recovery. If there are more or less cluster members than before the shutdown, recovery throws an exception. When the fast_load_only is used; it is advisable to set Cache Agent Quorum to the total number of cache nodes. This increases the chances of a successful recovery.

    • The robust_load_only forces slow recovery.

Default value is: no_data_loss.

Note: The seeder information (the current seeder list) is stored in the Shared Nothing persistence files during shutdown. This information is then used during startup or restart to perform recovery. If the cluster is exactly the same during startup (that is, exactly the same members are available and quorum is satisfied), then fast loading of the data is performed.
be.engine.cluster.recovery.distributed.batchsize
  When distributed batch recovery is enabled (be.engine.cluster.recovery.distributed.strategy=batch), the recovery manager divides the target table into many smaller batches and assigns 1-to-n number of these batches to each node (for them to execute recovery).

This parameter provides an approximation to the size of each such batch. Since batches are defined using the target table's key field (for example, approximated using ID$ column), actual batch size will differ depending on the key distribution.

Users can instead define be.engine.cluster.recovery.distributed.batchpernode=2 and prevent that too few, or too many batches are created.

be.engine.cluster.useDBBatching
 
Note
For use with cache aside and only when the parallel operations feature is used.

This property has no effect if Agent.AgentClassName.dbOpsBatchSize is set to 1 (see Table 14, CDD Agent Classes Tab Inference Agent and Query Agent Properties, ).

This property affects how all RTC transactions that a database writer thread takes from the database operations queue are written to the backing store:

  • When set to true, the RTC transactions are handled as one job.
  • When set to false, each RTC transaction is handled as a separate job.

For a guide to usage of this and other related properties, refer to the "Database Write Tuning Options for Cache Aside" section in the TIBCO BusinessEvents Architect’s Guide.

Default value is false.

be.jdbc.multibyte.support
  You can specify whether multibyte characters are supported in the column values.

Set the value to true for the Microsoft SQL Server where multibyte character support is required.

The default value is false.