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.
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.
|
|
be.backingstore.dburi.pool.inactivityTimeout.0 |
|
|
|
be.backingstore.readtimeout |
|
|
|
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.
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 |
|
|