Backing Store Write Options — Cache-aside and Write-behind

Writes to the backing store can be done in either of two ways: cache-aside, in which the inference agent handles all writes simultaneously, and offers transaction control; or write-behind, in which the cache agent handles writes to cache then database.

For most systems, especially those with a lot of I/O, including updates and deletes within an RTC, cache-aside is recommended.

Cache-aside

With cache-aside database write strategy, inference agents manage writes to the cache, the local L1 cache, and the backing store, simultaneously, in the post RTC phase. (The cache agent reads from the backing store, but does not write to it.)

Cache-aside allows batching of writes to the backing store and provides thread and queue size controls.

Write-behind

With write-behind database write strategy, the cache management layer handles writes to cache and to the backing store. First it writes data to the cache and then to the backing store. Writes are managed by the cache agents. For inserts and updates, one write-behind thread is used for each entity type. Deletes are performed by the distributed cache threads (configurable) and are synchronously deleted from the database.

Write operations from multiple writers to the cache are batched. Write-behind batches the writes during the delay period which increases database call efficiency and minimizes network traffic.

Write-behind does not offer transaction controls, and can be slower than cache-aside.

If enough cache agents fail, the cache management layer won’t be able to persist a write that was done previously, resulting in an inconsistent database.

Starting a Minimum Number (Quorum) of Cache Agents

At system startup, one node in the cache cluster loads objects from the backing store to the cache cluster, according to the preloading settings (see Storage and Retrieval of Entity Objects). Any node in the cluster can perform the preloading.

Before preloading begins, you must ensure that enough cache agents have started to hold the objects from the backing store. The cluster does not start processing incoming data until the required objects have been loaded into the cache.

See Cache OM and Cluster Configuration in TIBCO BusinessEvents Configuration Guide, for details on specifying the minimum number of cache agents that must start before cache loading begins.

After the specified number of cache agents has started, the processing unit that acquires the lock first performs the cache loading. Any processing unit can acquire the lock. All agents wait until backing store data has finished loading before they start.

Note: This setting does not affect runtime operation of the deployed application. Deployed applications continue to run even if one or more cache agents fails and the quorum is no longer met. A warning message is written to the log file.