public enum CacheAtomicityMode extends Enum<CacheAtomicityMode>
ATOMIC
mode is
used whenever transactions and explicit locking are not needed. Note that in ATOMIC
mode cache will still maintain full data consistency across all cache nodes.
Cache atomicity may be set via CacheConfiguration.getAtomicityMode()
configuration property.
Enum Constant and Description |
---|
ATOMIC
Specifies atomic-only cache behaviour.
|
TRANSACTIONAL
Enables fully
ACID -compliant transactional cache behavior for the key-value API. |
Modifier and Type | Method and Description |
---|---|
static @Nullable CacheAtomicityMode |
fromOrdinal(int ord)
Efficiently gets enumerated value from its ordinal.
|
static CacheAtomicityMode |
valueOf(String name)
Returns the enum constant of this type with the specified name.
|
static CacheAtomicityMode[] |
values()
Returns an array containing the constants of this enum type, in
the order they are declared.
|
public static final CacheAtomicityMode TRANSACTIONAL
ACID
-compliant transactional cache behavior for the key-value API.
See Transaction
for more information about transactions.
public static final CacheAtomicityMode ATOMIC
In addition to transactions and locking, one of the main differences in ATOMIC
mode
is that bulk writes, such as putAll(...)
, removeAll(...)
, and transformAll(...)
methods, become simple batch operations which can partially fail. In case of partial
failure CachePartialUpdateException
will 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 makes best effort to provide
full consistency guarantees across all cache nodes. However, in following scenarios (but not limited to)
full consistency is not possible and TRANSACTIONAL
mode should be used or custom defined recovery
logic should be applied to restore data consistency:
put(...)
, putAll(...)
, remove(K, V)
and removeAll(Set<K>)
all copies of partitions will come to a consistent state.
EntryProcessor
is used and processor is not idempotent then failure of primary node
may result in applying the same processor on next chosen primary which may have already been
updated within current operation. If processor is not idempotent it is recommended to disable
automatic retries and manually restore consistency between key-value copies in case of update failure.
putIfAbsent(K, V)
, replace(K, V, V)
and remove(K, V)
return
value on primary node crash may be incorrect because of the automatic retries. It is recommended
to disable retries with IgniteCache.withNoRetries()
and manually restore primary-backup
consistency in case of update failure.
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.
Note! Consistency behavior of atomic cache will be improved in future releases.
IgniteCache.withNoRetries()
public static CacheAtomicityMode[] values()
for (CacheAtomicityMode c : CacheAtomicityMode.values()) System.out.println(c);
public static CacheAtomicityMode valueOf(String name)
name
- the name of the enum constant to be returned.IllegalArgumentException
- if this enum type has no constant with the specified nameNullPointerException
- if the argument is null@Nullable public static @Nullable CacheAtomicityMode fromOrdinal(int ord)
ord
- Ordinal value.null
if ordinal out of range.
Follow @ApacheIgnite
Ignite Database and Caching Platform : ver. 2.16.0 Release Date : December 15 2023