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.To implement a backing store, you need to 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 Configuration in TIBCO BusinessEvents Administration for more details.A legacy Oracle-only backing store implementation is also maintained in this release but is deprecated.Various options are available for configuring the backing store for your needs, and for using it to support your data persistence and access 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.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.Cache-aside is a later implementation to offer improved controls based on experiences with the earlier write-behind method.For most systems, especially those with a lot of I/O, including updates and deletes within an RTC, cache-aside is generally recommended.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 provides transaction control, making sure transactions, including deletes, are performed following an RTC. It allows batching of Rete transactions (RTCs) and provides thread and queue size controls.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 they are synchronously deleted from the database.You can configure a write-delay property to define whether the write is synchronous or asynchronous.Write-behind batches the writes during the delay period which increases database call efficiency and minimizes network traffic.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. (This risk can be minimized by using a short write-behind delay or synchronous writes.)
Copyright © TIBCO Software Inc. All Rights Reserved.