Chapter 25 Project Configuration for Backing Store : Project Configuration for Backing Store—Overview

Project Configuration for Backing Store—Overview
You can implement a backing store for use with any cache option. Various aspects of backing store behavior are configurable, as explained in this chapter.
Backing Store Configuration Builds on Cache Configuration
It’s a good idea to configure and test caching features before adding backing store functionality. This section explains only the properties relating to backing store functionality.
For cache-related configuration see Chapter 17, Understanding Cache OM and Multi-Engine Features and chapters following.
Backing Store Configuration Summary
To set up a backing store you must complete the following activities:
Backing Store Runtime Behavior
During regular operation, cache data is written to the backing store by the cache cluster. Only cache servers write to the backing store. Inference agents and query agents are not involved in writes to the database.
At system startup, the data is loaded into the cache from the backing store, using any one of the nodes (including nodes running inference agents and query agents).
Options to configure these behaviors are explained next.
Reading From the Backing Store at Startup
At system startup, after the minimum number of cache servers have started, the cache is loaded with backing store data. This occurs before the agents begin to process events or execute startup functions.
Any node in the cluster can load data from the backing store to the cache at startup. This is why you must add all the backing store properties to all the engine property files.
You can configure the system so that only certain objects are loaded into the cache from the backing store at startup. See Preloading Options for Cache Only Objects.
See Configuring How Backing Store Data is Loaded at Startup.
Reading From the Backing Store At Runtime
At runtime, if an object is not in working memory it is requested from the cache. If it is not in the cache, the cache server retrieves that object from the backing store.
At runtime, only the cache servers interact with the backing store.
Writing to the Backing Store
After an RTC, data is written to the cache, and then the cache writes the data to the backing store.
Only nodes that store cache data (also known as storage nodes), write to the backing store. Any node can be configured as a storage node (cache server) using the following property:
java.property.tangosol.coherence.distributed.localstorage=true
However, it is a best practice to enable storage only on specialized nodes, called cache server nodes.
See Cache Server Configuration Overview for details.
Additional Configuration Options
Other configuration options relating to performance and debugging are listed next. They are described in the reference table, Engine TRA File Reference for Backing Store Settings.
Number of rows to pre-fetch during database reads:
be.engine.tangosol.oracle.prefetch
Summary List of Backing Store Related Properties
The following is a complete listing backing store properties discussed in this chapter:

 
# Backing Store Related Properties
be.engine.cluster.hasBackingStore
be.engine.cluster.isCacheLimited
java.property.be.engine.limited.cache.back.size.limit
be.oracle.dburi.0
be.oracle.dburi.pool.initial.0
be.oracle.dburi.pool.min.0
be.oracle.dburi.pool.max.0
be.oracle.dburi.pool.enforce.0
 
be.oracle.debug
be.engine.tangosol.oracle.prefetch
be.engine.tangosol.oracle.batchSize
 
# Only one preload choice is allowed. Pick one: none, include, or
# exclude. All options are shown below as examples only:
be.engine.cluster.preload=none
# OR
be.engine.cluster.preload=include
be.engine.cluster.EntityClassName.preload=true
# OR
be.engine.cluster.preload=exclude
be.engine.cluster.EntityClassName.preload=false