Apache Ignite.NET Documentation

The Apache Ignite .NET Developer Hub

Welcome to the Apache Ignite .NET developer hub. You'll find comprehensive guides and documentation to help you start working with Apache Ignite.NET as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

3rd Party Persistence

Write-through or read-through data to and from external persistent storage.

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

Read-Through and Write-Through

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.

Write-Behind Caching

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.



ICacheStore is 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.

Load(), Write(), Delete()

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.

LoadAll(), WriteAll(), DeleteAll()

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.


CacheStoreAdapter provides default implementation for LoadAll(), WriteAll(), and DeleteAll() 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.


CacheStoreAdapter provides default empty implementation of SessionEnd() 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:

Setter MethodDescriptionDefault
WriteBehindEnabledSets flag indicating whether write-behind is enabled.false
WriteBehindFlushSizeMaximum 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
WriteBehindFlushFrequencyFrequency 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
WriteBehindFlushThreadCountNumber of threads that will perform cache flushing.1
WriteBehindBatchSizeMaximum 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()}
            <cacheStoreFactory type="MyNamespace.MyStoreFactory, MyAssembly" />
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="cacheConfiguration">
        <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"/>

More Info

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 7 months ago

3rd Party Persistence

Write-through or read-through data to and from external persistent storage.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.