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.
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.
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.
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.)