Atomicity mode and read-after-write consistency

[bsmets <ba...@inventivegroup.com>]

I have a question about consistency between nodes in an ignite cluster. We
are writing entries into an ignite cache on one node and reading the same
entry on another node just 1 second later but we observe that this second
node does not yet contain the entry. Is this normal behaviour?

Note that we are not using any transactions.

I read on http://apacheignite.gridgain.org/v1.2/docs/transactions that even
when using atomic mode, atomicity and consistency across nodes is
guaranteed. Does this mean that reads after a write are always guaranteed to
return the written value?



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Atomicity-mode-and-read-after-write-consistency-tp3391.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Atomicity mode and read-after-write consistency

[Alexey Goncharuk <al...@gmail.com>]

Hi,

Consistency between nodes is guaranteed in ATOMIC mode, however, the
read-after-write guarantee is met in the following cases:
 - cache write synchronization mode is FULL_SYNC. In this mode cache.put()
will not return control until all data nodes (primary and backup)
responsible for the data are updated. See
CacheConfiguration.setWriteSynchronizationMode()
 - cache write synchronization mode is PRIMARY_SYNC, but reads from backups
are forbidden by setting CacheConfiguration#readFromBackup to false. In
this mode cache.put() will return control after the primary node has been
updated (backup nodes may not be updated yet), the the read consistency is
guaranteed because reads always happen from primary nodes.

Both modes have it's implications on performance - FULL_SYNC mode comes at
a slightly slower update performance while it allows more frequent local
reads using backups; PRIMARY_SYNC allows for a better update performance,
but the restriction for always-primary reads will result in more frequent
network calls for reads. It's up to you to decide which configuration suits
better for your use-case.

Hop this helps,
--AG