Strategies for persisting system data
You can persist system data (entity data, and data that represents the state of the system) by changing the configuration in the objectgrid.xml file. Although a backing database is typically used in production, by default Decision Server Insights is not configured for persistence.
You can configure Decision Server Insights to write system data to a backend database either synchronously (write-through), or asynchronously (write-behind).
Before you configure persistence, you must consider how important your data is, and whether you want changes to system data to be synchronized with the database. You must also consider how often changes are likely to occur to system data, and the effect that persistence can have on system performance.
Write-through (synchronous update)
If you configure write-through, Decision Server Insights writes updates to the database as part of each event processing transaction. Write-through provides better data integrity after a total cluster failure than write-behind, but involves more database operations. You can use write-through if you are concerned about data integrity in a total cluster failure, and you are not concerned about extra database operations. Write-through is also suitable for non-high-availability (HA) topologies, where there is no in-memory redundancy.
Write-behind (asynchronous update)
If you configure write-behind, Decision Server Insights aggregates multiple updates before it writes them to the database as a single operation. You can configure the write operation to occur after a specified number of changes, or after a predetermined interval. If the database is not available, Decision Server Insights queues the updates, and applications can continue to send transactions. When the database recovers, Decision Server Insights writes the queued updates to the database as a single operation. Use write-behind to improve system performance of HA topologies. You can use write-behind if overall cluster performance is important and total cluster failure is considered unlikely.
Because data is replicated across the servers of the cluster there is no risk of losing data when you use write-behind in a HA topology, except when all the servers in a cluster are lost simultaneously in a site-wide outage. When you shut down a cluster manually, be sure to shut down inbound connectivity before you shut down the other server types. If events are still being processed, when the last server in an HA cluster is shut down, write-behind data might be lost.
Cache in memory (no persistence)
Decision Server Insights caches updates in memory by default but you cannot manage memory consumption. If the system stops for any reason, the updates are discarded. You can use cache in memory for noncritical data that can be discarded.