Open topic with navigation

TIBCO BusinessEvents® Enterprise Edition 6.3.1

# 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 the Min Size and Max Size properties (in Configuring Backing Store for Cache OM ). The 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. The 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 changes and the agent restarts.
    be.engine.cluster.recovery.threads
| Recovery threads are used to 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 are 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, 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 the 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 generates an exception. The `fast_load_only` recovers the space only if all the members that were active before the shutdown are available in the cluster. This policy enables fast recovery. If there are more or less cluster members than before the shutdown, recovery generates 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. The default value is: `no_data_loss`. Note: The seeder information (the current seeder list) is stored in the Shared Nothing persistence file during shutdown. This information is then used during startup or restart, to perform recovery. If the cluster is the same during startup (that is, 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 the 1-to-n number of these batches to each node (for them to run 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 the ID$ column), actual batch size differs depending on the key distribution. Note: In case of the legacy lookup strategy (default), the batch size is a numeric value as set by you to manage the range but with the 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. The 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`.

Did you find this helpful?

YesNo
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO BusinessEvents® Enterprise Edition

Copyright © 2004-2024. Cloud Software Group, Inc. All Rights Reserved.