Bug 1167780 - Specify & document cache consistency guarantees
Summary: Specify & document cache consistency guarantees
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Documentation, Infinispan
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 6.5.0
Assignee: Christian Huffman
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2014-11-25 12:05 UTC by Radim Vansa
Modified: 2019-01-30 19:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2019-01-30 19:47:41 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-4995 0 Critical Resolved ClusteredGet served for non-member of CH 2019-01-30 19:47:20 UTC
Red Hat Issue Tracker ISPN-5016 0 Critical Open Specify and document cache consistency guarantees 2019-01-30 19:47:20 UTC

Description Radim Vansa 2014-11-25 12:05:18 UTC
This BZ should cover specification & inclusion into documentation of consistency guarantees for cache operations, given certain configurations.

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/JDG.

Infinispan documentation is quite scarce about that, the only trace I've found is in Glossary: "Infinispan has traditionally followed ACID principles as far as possible, however an eventually consistent mode embracing BASE is on the roadmap.", and I don't think there is anything better in product docs.

Comment 1 Radim Vansa 2014-11-25 12:06:19 UTC
Adding JIRA that contains one situation in which the 'correct' behaviour of cache is questionable.

Comment 3 Radim Vansa 2014-11-25 12:12:27 UTC
Community documentation JIRA

Comment 4 Misha H. Ali 2014-12-03 06:31:18 UTC
Checking with Dan about what the consistency guarantee we want to provide is.

Comment 6 JBoss JIRA Server 2014-12-31 09:01:23 UTC
Dan Berindei <dberinde@redhat.com> updated the status of jira ISPN-4995 to Resolved

Comment 8 Radim Vansa 2015-01-26 15:44:58 UTC
Hi Misha, is there some time left so you could add one more warning box to the Network Partition Handling document, related to ISPN-4995? (linked to this BZ, resolved as Won't Fix - therefore it should be a documented behavior)

Between the time (t1) when partitions begin merging to the time (t2) when the merge is complete, nodes reconnect through a series of merge events. During this time window, it is possible that a node can be reported as having temporarily left the cluster. This node may not detect that it has been removed from the cluster (and enter Degraded Mode) but writes in the cluster are not executed on this node. Therefore, it can return stale values for some of the entries.

This is in fact the same issue as documented in 1.2, first warning box, third point: 'There is also a possibility of a stale read in a minor partition during this transition period, as an entry is still Available until the minor partition enters Degraded state.', but it may not be obvious that there can be logical split while physical merge occurs.

Comment 15 Christian Huffman 2019-01-30 19:47:41 UTC
I'm closing this issue out due to age. If it persists, file a corresponding JIRA.

Note You need to log in before you can comment on or make changes to this bug.