Cluster Deployment Descriptor Reference : Cluster Tab — Cache OM — Object Management Settings

Cluster Tab — Cache OM — Object Management Settings
TIBCO BusinessEvents Express  This section relates to Cache OM functionality and does not apply to TIBCO BusinessEvents Express edition.
For the related procedure, see Configuring a Cache OM Cluster — Cluster Tab
Specifies a minimum number (quorum) of storage-enabled nodes that must be active in the cluster when the system starts up before the following occur:
The property does not affect the running of the deployed application after startup (though a message is written to the log file if the number of cache agents running falls below the number specified in this property).
The number of backup copies (also known as the backup count) specifies the number of members of the distributed cache service that hold the backup data for each unit of storage in the cache. Recommended values are 0, 1, or 2.
Value of 0 means that in the case of abnormal termination, some portion of the data in the cache will be lost. Value of N means that if up to N cluster nodes terminate at once, the cache data will be preserved.
A backup count of 1 means one server plus one backup are needed, that is, two cache agents (or storage enabled nodes if cache agents are not used).
To maintain the partitioned cache of size M, the total memory usage in the cluster does not depend on the number of cluster nodes and will be in the order of M*(N+1).
See Synchronous and Asynchronous Replication of Cache Objects for details on replication behavior and options for TIBCO BusinessEvents DataGrid.
Specifies the size of the limited cache, in number of cache entries for each object type in each agent where local storage is enabled (cache agents, and other agents where the local storage property is explicitly enabled).
See The Role of the Object Table in TIBCO BusinessEvents Architect’s Guide for more details about the object table.
Synchronous and Asynchronous Replication of Cache Objects
When you set a backup count, you define the number of backup object copies to make, in addition to the primary cache object. Backup cache writes can be done synchronously or asynchronously. There is a difference between the behavior of TIBCO BusinessEvents DataGrid and for Oracle Coherence as regards replication.
TIBCO BusinessEvents DataGrid Uses Asynchronous Replication
TIBCO BusinessEvents DataGrid is set up to use asynchronous replication. There is no option to use synchronous replication. Asynchronous replication allows you to run tests using a single cache agent.
With asynchronous replication, the inference agent writes to a cache agent and returns. The cache provider then makes a separate call to another cache agent to make the replica. This means that the writes from the inference agent do not incur the cost of synchronous replication, because replication happens on a different thread in the background. However, a small window exists in which the inference agent has written to the cache, and the cache provider has not replicated the data yet. If the cache agent fails at this point, data is lost because there is no replica. To safeguard the data, use a backing store with cache-aside database write strategy.
Oracle Coherence Uses Synchronous Replication
With Oracle Coherence as the cache provider, TIBCO BusinessEvents is set up to use synchronous replication. There is no option to use asynchronous replication.
With synchronous replication, when the inference agent writes to the cache, the cache provider makes a network call to another cache agent and makes a replica (or replicas) and then the call from the inference agent returns. This means making two cache puts for each cache operation. Therefore, synchronous replication is slower than asynchronous replication.
You must also ensure that the required number of cache agents is always up and running (depending on the backup count).