[infinispan-issues] [JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029278#comment-13029278 ] 

Radim Vansa commented on ISPN-5016:
-----------------------------------

{quote}Because data is stored in the shared store after the invalidation command was executed on all the nodes, it’s also possible for a node to read the old value from the shared store after it has executed the invalidation.{quote}
I don't understand the reason very well, could you elaborate a bit more?

{quote}Invalidations triggered by write operations are synchronous and the operation will fail with a SuspectException if another node crashes. The entry will not be updated on the originator, but invalidation will still be performed on the non-crashed nodes.{quote}
I thought SuspectExceptions are silently handled, aren't they?

{quote}For multi-key operations like putAll(), the operation is sent to all the primary owners of the affected keys. When there is a single primary owner for all the affected keys, the operation succeeds and its effects are visible atomically. When there are multiple primary owners, the operation is not atomic: overlapping read operations will see random subsets of the updated values.{quote}
As reads don't acquire any locks, I think that even update on single primary owner can be seen as non-atomic.



> Specify and document cache consistency guarantees
> -------------------------------------------------
>
>                 Key: ISPN-5016
>                 URL: https://issues.jboss.org/browse/ISPN-5016
>             Project: Infinispan
>          Issue Type: Task
>          Components: Documentation-Core
>    Affects Versions: 7.0.2.Final
>            Reporter: Radim Vansa
>            Assignee: Dan Berindei
>            Priority: Critical
>
> We can't simply use the consistency model defined by Java Specification and broaden it for whole cache (maybe the expression "can't" is too strong, but we definitely don't want to do that in some cases).
> By consistency guarantees/model I mean mostly in which order are 
> writes allowed to be observed: and we can't boil it down to simply 
> causal, PRAM or any other consistency model as writes can be observed as non-atomic in Infinispan.
> Infinispan documentation is quite scarce about that, the only trace I've 
> found is in Glossarry [2] "Infinispan has traditionally followed ACID 
> principles as far as possible, however an eventually consistent mode 
> embracing BASE is on the roadmap."



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)