Distributed Cache OM : Cache OM with a Backing Store

Cache OM with a Backing Store
You can implement a backing store for use with Cache OM to provide data persistence.
During regular operation, cache data is written to the backing store. On system restart, data in the backing store is restored to the cache cluster.
Implementing a Backing Store
To implement a backing store, you provide a supported database product. Scripts are provided to set up the database for your project’s ontology. If the ontology changes, scripts help you adapt the backing store accordingly (though some manual work may be required depending on the nature of the changes). Existing backing store data can be preserved.
See Chapter 15, JDBC Backing Store Setup in TIBCO BusinessEvents Administration for more details.
Configuring Backing Store Options
Various options are available for configuring the backing store for your needs, as explained in this chapter. See Managing Storage and Retrieval of Entity Objects for more information about fine grained controls over data storage and retrieval.
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 Rete transactions (RTCs) 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.