Bug 1167780

Summary:	Specify & document cache consistency guarantees
Product:	[JBoss] JBoss Data Grid 6	Reporter:	Radim Vansa <rvansa>
Component:	Documentation, Infinispan	Assignee:	Christian Huffman <chuffman>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.4.0	CC:	afield, chuffman, jdg-bugs, jpallich, mharvey, mlittle, pzapataf, wfink
Target Milestone:	GA
Target Release:	6.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-01-30 19:47:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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