Threading Models and Tuning : Post RTC Options — Cache-aside and Write-behind

Post RTC Options — Cache-aside and Write-behind
In the post RTC phase, the cache is updated, outgoing events are sent, the backing store is updated, and locks (if any) are released. TIBCO BusinessEvents handles outgoing events on a separate set of threads, in both the write-behind and cache-aside options. However, each option handles writing to cache and to the backing store differently, as shown next.
Cache-aside
With cache-aside, inference agents manage writes to the cache, the local L1 cache, and the backing store, simultaneously in the post RTC phase.
When writing to the database, TIBCO BusinessEvents does the following actions in a single transaction:
deleteConcepts
deleteEvents
insertConcepts
insertEvents
modifyConcepts
removeObjectTable
saveObjectTable
Multiple transactions can be committed in one batch. The size of the batch is controlled by the Agent.AgentClassName.dbOpsBatchSize property as shown in the section Tuning Properties for Cache-aside Strategy.
Tuning Properties for Cache-aside Strategy
Add to a CDD property sheet, at the level of Agent Classes, Processing Units, or Cluster, depending on the scope of the setting. For example to apply the settings to all agents in a cluster, set the property at the cluster level. You can also override the value at a lower level.
Agent.AgentClassName.threadcount
Tip  This property is also used to define the number of Recovery threads (used for recovering Cache Plus Memory entity handles at inference engine startup).
Agent.AgentClassName.dbOpsQueueSize
Defines the size of the Java BlockingQueue for database writing jobs.
Agent.AgentClassName.dbthreadcount
Agent.AgentClassName.dbOpsBatchSize
Advantages
Offers the ability to use the database as the primary storage, and to use cache secondarily, to pass the objects between the Rete network and the database. This strategy is useful in some usage scenarios.
Disadvantages
There are really no disadvantages in comparison with write-behind. Cache-aside is a later implementation to offer improved controls based on experiences with the earlier write-behind method.
Write-behind
With write-behind strategy, cache agents handle writes to cache and to the backing store. First the cache agent writes data to the cache and then to the backing store.
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 operations from multiple writers to the cache are batched.
Advantages
Disadvantages
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 DB (This risk can be minimized by using a short write-behind delay or synchronous writes).
Cache Agent Thread tuning
Uses the following cluster-wide property:
java.property.tangosol.coherence.distributed.threads
Specifies the number of Coherence daemon threads used by the distributed cache service. If zero, all relevant tasks are performed on the service thread.