Apache Ignite.NET
|
Ignite Configuration API. More...
Classes | |
class | CacheConfiguration |
Defines grid cache configuration. More... | |
class | MemoryConfiguration |
A page memory configuration for an Apache Ignite node. The page memory is a manageable off-heap based memory architecture that divides all continuously allocated memory regions into pages of fixed size. An individual page can store one or many cache key-value entries that allows reusing the memory in the most efficient way and avoid memory fragmentation issues. More... | |
class | MemoryPolicyConfiguration |
Defines page memory policy configuration. See MemoryConfiguration.MemoryPolicies. More... | |
class | NearCacheConfiguration |
Defines near cache configuration. More... | |
class | QueryAlias |
Represents cache query configuration alias. More... | |
class | QueryEntity |
Query entity is a description of cache entry (composed of key and value) in a way of how it must be indexed and can be queried. More... | |
class | QueryField |
Represents a queryable field. More... | |
class | QueryIndex |
Represents cache query index configuration. More... | |
class | QueryIndexField |
Represents an indexed field. More... | |
class | QuerySqlFieldAttribute |
Marks field or property for SQL queries. More... | |
class | QueryTextFieldAttribute |
Marks field or property for Text queries. More... | |
Typedefs | |
using | BinaryReader = Apache.Ignite.Core.Impl.Binary.BinaryReader |
using | BinaryWriter = Apache.Ignite.Core.Impl.Binary.BinaryWriter |
using Apache.Ignite.Core.Cache.Configuration.BinaryReader = typedef Apache.Ignite.Core.Impl.Binary.BinaryReader |
using Apache.Ignite.Core.Cache.Configuration.BinaryWriter = typedef Apache.Ignite.Core.Impl.Binary.BinaryWriter |
Enumerator | |
---|---|
Transactional |
Specifies fully ACID-compliant transactional cache behavior. |
Atomic |
Specifies atomic-only cache behaviour. In this mode distributed transactions and distributed locking are not supported. Disabling transactions and locking allows to achieve much higher performance and throughput ratios. In addition to transactions and locking, one of the main differences to Atomic mode is that bulk writes, such as ICache<TK,TV>.PutAll and ICache<TK,TV>.RemoveAll(System.Collections.Generic.IEnumerable<TK>) methods, become simple batch operations which can partially fail. In case of partial failure, CachePartialUpdateExceptionwill be thrown which will contain a list of keys for which the update failed. It is recommended that bulk writes are used whenever multiple keys need to be inserted or updated in cache, as they reduce number of network trips and provide better performance. Note that even without locking and transactions, Atomic mode still provides full consistency guarantees across all cache nodes. Also note that all data modifications in Atomic mode are guaranteed to be atomic and consistent with writes to the underlying persistent store, if one is configured. |
Enumerator | |
---|---|
Local |
Specifies local-only cache behaviour. In this mode caches residing on different grid nodes will not know about each other. Other than distribution, Local caches still have all the caching features, such as eviction, expiration, swapping, querying, etc... This mode is very useful when caching read-only data or data that automatically expires at a certain interval and then automatically reloaded from persistence store. |
Replicated |
Specifies fully replicated cache behavior. In this mode all the keys are distributed to all participating nodes. |
Partitioned |
Specifies partitioned cache behaviour. In this mode the overall key set will be divided into partitions and all partitions will be split equally between participating nodes. Note that partitioned cache is always fronted by local 'near' cache which stores most recent data. |
Replicated caches will try to load the full set of cache entries from other nodes, while partitioned caches will only load the entries for which current node is primary or backup.
Note that rebalance mode only makes sense for CacheMode.Replicated and CacheMode.Partitioned caches. Caches with CacheMode.Local mode are local by definition and therefore cannot rebalance any values from neighboring nodes.
Enumerator | |
---|---|
FullSync |
Mode indicating that Ignite should wait for write or commit replies from all nodes. This behavior guarantees that whenever any of the atomic or transactional writes complete, all other participating nodes which cache the written data have been updated. |
FullAsync |
Flag indicating that Ignite will not wait for write or commit responses from participating nodes, which means that remote nodes may get their state updated a bit after any of the cache write methods complete, or after Transaction#commit() method completes. |
PrimarySync |
This flag only makes sense for CacheMode#PARTITIONED mode. When enabled, Ignite will wait for write or commit to complete on primary node, but will not wait for backups to be updated. |
Enumerator | |
---|---|
Disabled |
Eviction is disabled. |
RandomLru |
Random-LRU algorithm. Once a memory region defined by a memory policy is configured, an off-heap array is allocated to track last usage timestamp for every individual data page. The size of the array equals to MemoryPolicyConfiguration.MaxSize / MemoryConfiguration.PageSize. When a data page is accessed, its timestamp gets updated in the tracking array. The page index in the tracking array equals to pageAddress / MemoryPolicyConfiguration.MaxSize. When some pages need to be evicted, the algorithm randomly chooses 5 indexes from the tracking array and evicts a page with the latest timestamp. If some of the indexes point to non-data pages (index or system pages) then the algorithm picks other pages. |
Random2Lru |
Activates Random-2-LRU algorithm which is a scan resistant version of Random-LRU. This algorithm differs from Random-LRU only in a way that two latest access timestamps are stored for every data page. At the eviction time, a minimum between two latest timestamps is taken for further comparison with minimums of other pages that might be evicted. LRU-2 outperforms LRU by resolving "one-hit wonder" problem - if a data page is accessed rarely, but accidentally accessed once, its protected from eviction for a long time. |
All Safe policies prevent a user from interaction with partial data in lost partitions until IIgnite.ResetLostPartitions(IEnumerable<string>) method is called.
*All policies allow working with partial data in lost partitions.
ReadOnly and ReadWrite* policies do not automatically change partition state and thus do not change rebalancing assignments for such partitions.