[infinispan-issues] [JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees
Radim Vansa (JIRA)
issues at jboss.org
Tue Dec 23 08:09:30 EST 2014
[ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029387#comment-13029387 ]
Radim Vansa commented on ISPN-5016:
-----------------------------------
{quote}TODO What happens if a node is a backup owner for two of the keys?{quote}
Hmm? The primary owner sends the PutMapCommand to all nodes that are backup owners of at least one of the keys primary-owned by this node. But you're right that I am not sure whether this command makes the backup node write only
{quote}When a node tries to read a key it does not own, it sends a remote get{quote}
AFAIK the node checks if the entry is in data container, not whether it is owned.
Regarding the situation that an entry is lost, I think that you should note somewhere that further attempts to read it will simply return null, not throwing any exceptions (the user could expect that).
I lack explicit resolution on ISPN-4995, regarding reading and writing two (or more) entries and expectation whether any read is already visible.
And in the end, I think that there should be a summarized table for the modes and ticks or crosses whether the cache will stay consistent after originator crash, primary owner crash, timeout exception/another exception.
I think this is the best design document on Infinispan cache API so far. Thanks a lot, Dan, for the effort to put it together. I hope at least some users will be willing to read it (as it took me several hours just to go through it).
> 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)
More information about the infinispan-issues
mailing list