CDD Cluster Tab Backing Store Properties Reference

Use this reference for the backing store properties.

For the related procedure, see Configuring Backing Store for Cache OM.

CDD Cluster Tab Backing Store Properties
Property Notes
Database Connection Properties
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 Configuring Backing Store for Cache OM ).

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.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.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 Domain Objects Configuration.

Default is 5.

be.engine.cluster.recovery.distributed.strategy 
  This property is used for Shared All and for Shared Nothing persistence.
  • For Store: 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.

Note: In case of legacy lookup strategy (default), the batch size is a numeric value as set by you to manage range but with new key-based lookup strategy (be.engine.id.useLegacy=false), the range rather is based on the timestamp.

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 CDD Agent Classes Tab Properties Reference ).

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.