Apache Ignite .NET in-memory cache provides ICacheStore API for write-through and read-through to and from an underlying persistent storage respectively (e.g. an RDBMS like Oracle or MSSQL, or NoSQL database like MongoDB or Couchbase).
Providing proper cache store implementation is important whenever read-through or write-through behavior is desired. Read-through means that data will be read from persistent store whenever itβs not available in cache, and write-through means that data will be automatically persisted whenever it is updated in cache. All read-through and write-through operations will participate in overall cache transaction and will be committed or rolled back as a whole.
To configure read-through and write-through, you need to implement ICacheStore interface and set cacheStoreFactory as well as readThrough and writeThrough properties of CacheConfiguration in Spring XML, as shown in examples below.
In a simple write-through mode each cache put and remove operation will involve a corresponding request to the persistent storage and therefore the overall duration of the cache update might be relatively long. Additionally, an intensive cache update rate can cause an extremely high storage load.
For such cases, Ignite offers an option to perform an asynchronous persistent store update also known as write-behind. The key concept of this approach is to accumulate updates and then asynchronously flush them to persistent store as a bulk operation. The actual data persistence can be triggered by time-based events (the maximum time that data entry can reside in the queue is limited), by queue-size events (the queue is flushed when itβs size reaches some particular point), or by using both of them in combination in which case either event will trigger the flush.
πUpdate Sequence
With the write-behind approach only the last update to an entry will be written to the underlying storage. If cache entry with key key1 is sequentially updated with values value1, value2, and value3 respectively, then only single store request for (key1, value3) pair will be propagated to the persistent storage.
πUpdate Performance
Batch store operations are usually more efficient than a sequence of single store operations, so one can exploit this feature by enabling batch operations in write-behind mode. Update sequences of similar types (put or remove) can be grouped to a single batch. For example, sequential cache puts of (key1, value1), (key2, value2), (key3, value3) will be batched into a single
CacheStore.putAll(...)operation.
Write-behind caching can be enabled via CacheConfiguration.writeBehindEnabled configuration property. See configuration section below for a full list of configuration properties that allow to customize the behavior of write-behind caching.
ICacheStore interface in Ignite .NET is used to write and load data to and from the underlying data store.
πTransactions
ICacheStoreis fully transactional and automatically merges into the ongoing cache transaction.
ICacheStore.LoadCache() method allows for cache loading even without passing all the keys that need to be loaded. It is generally used for hot-loading the cache on startup, but can be also called at any point after the cache has been started.
ICache.LoadCache() method will delegate to ICacheStore.LoadCache() method on every cluster member that is running the cache. To invoke loading only on the local cluster node, use ICache.LocalLoadCache() method.
πIn case of partitioned caches, keys that are not mapped to this node, either as primary or backups, will be automatically discarded by the cache.
Methods Load(), Write(), and Delete() on the ICacheStore are called whenever methods Get(), Put(), and Remove() are called correspondingly on the ICache interface. These methods are used to enable read-through and write-through behavior when working with individual cache entries.
Methods LoadAll(), WriteAll(), and DeleteAll() on the ICacheStore are called whenever methods GetAll(), PutAll(), and RemoveAll() are called correspondingly on the ICache interface. These methods are used to enable read-through and write-through behavior when working with multiple cache entries and should generally be implemented using batch operations to provide better performance.
π
CacheStoreAdapterprovides default implementation forLoadAll(),WriteAll(), andDeleteAll()methods which simply iterates through all keys one by one.
Ignite has a concept of store session which may span more than one cache store operation. Sessions are especially useful when working with transactions.
In case of ATOMIC caches, method SessionEnd() is called after completion of each ICacheStore method. In case of TRANSACTIONAL caches, SessionEnd() is called at the end of each transaction, which allows to either commit or rollback multiple operations on the underlying persistent store.
π
CacheStoreAdapterprovides default empty implementation ofSessionEnd()method.
The main purpose of cache store session is to hold the context between multiple store invocations whenever ICacheStore is used in a cache transaction. For example, if using a database as a persistent store, you can store the ongoing database connection. You can then commit this connection in the ICacheStore.SessionEnd(boolean) method.
CacheStoreSession can be injected into your cache store implementation via [StoreSessionResource] attribute.
Following configuration parameters can be used to enable and configure write-behind caching via IgniteConfiguration.CacheConfiguration:
WriteBehindEnabled Sets flag indicating whether write-behind is enabled. false WriteBehindFlushSize Maximum size of the write-behind cache. If cache size exceeds this value, all cached items are flushed to the cache store and write cache is cleared. If this value is 0, then flush is performed according to the flush frequency interval. Note that you cannot set both, flush size and flush frequency, to 0. 10240 WriteBehindFlushFrequency Frequency with which write-behind cache is flushed to the cache store in milliseconds. This value defines the maximum time interval between object insertion/deletion from the cache and the moment when corresponding operation is applied to the cache store. If this value is 0, then flush is performed according to the flush size. Note that you cannot set both, flush size and flush frequency, to 0. 5000 milliseconds WriteBehindFlushThreadCount Number of threads that will perform cache flushing. 1 WriteBehindBatchSize Maximum batch size for write-behind cache store operations. 512
ICacheStore interface can be set on CacheConfiguration in code or in app.config, or in Spring XML via PlatformDotNetCacheStoreFactory.
var cfg = new IgniteConfiguration
{
CacheConfiguration = new[]
{
new CacheConfiguration {CacheStoreFactory = new MyStoreFactory()}
}
};
<igniteConfiguration>
<cacheConfiguration>
<cacheConfiguration>
<cacheStoreFactory type="MyNamespace.MyStoreFactory, MyAssembly" />
</cacheConfiguration>
</cacheConfiguration>
</igniteConfiguration>
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
...
<property name="cacheConfiguration">
<list>
<bean class="org.apache.ignite.configuration.CacheConfiguration">
...
<property name="cacheStoreFactory">
<bean class="org.apache.ignite.platform.dotnet.PlatformDotNetCacheStoreFactory">
<property name="typeName" value="MyNamespace.MyStoreFactory, MyAssembly"/>
</bean>
</property>
...
</bean>
</list>
</property>
...
</bean>
Working example of cache store using Entity Framework + SQL database can be found in the blog post: ptupitsyn.github.io/Entity-Framework-Cache-Store/
Updated over 5 years ago
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4