[infinispan-dev] Dan's wiki page on cache consistency

[Dan Berindei]

On Tue, Dec 23, 2014 at 9:39 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> That's great, thanks a lot to Dan for writing it.
>
> But it's a very long document, and how would you all prefer to handle
> feedback, challenges and improvement proposals?

I think the best option is to clone the wiki repository on your
machine and add your comments inline with your favorite editor
(IntelliJ also has a nice plugin that lets you preview live in a split
editor). Just make sure to keep each sentence on a separate line to
minimize conflicts!

I tried moving it to GoogleDocs, but I had to go through HTML and I
lost all the formatting, so I gave up. Radim has posted some comments
in JIRA, but that doesn't look scalable. Let me know if you have other
suggestions!

> While this is probably the most faithful description of the (current)
> implementation - which is extremely helpful to users of the current
> version - I'd love to also start a debate on how we should improve it,
> so a clear distinction between
>  -A cases which match what Infinispan aims to be and therefore people
> should either live with it or look for a different solution
>  -B cases for which we agree they are a current limitation for which
> we have hopes to eventually improve on
>
> To be clear, I think some of the described semantics are unacceptable
> in practice, but I'm unsure on what would be the best platform to have
> such a debate; I'm afraid that by email we'd be focusing on the first
> raised points first while we should identify priorities, and being
> this a long document there are going to be lots of items to discuss.
>
> It might help a lot to classify A vs B cases to try and define a
> mission for the project. A selfish example for such a mission sound
> like "be an efficient and reliable way to store Lucene indexes for
> Hibernate Search", or "Aim to become the most efficient cache strategy
> for Hibernate".
> These are just examples, but would be helpful to define "current known
> bug" vs "unavoidable limitation".
> I realize that my very own view of "acceptable limitations" vs.
> "unacceptable" is defined by these use cases I have in mind.
> Especially the "key/value store" could use some clarification to see
> what we're aiming at.

Right, this wiki page isn't a design document as much as a description
of current limitations.

We should definitely have a proper design wiki page/google doc stating
what we want to achieve. Perhaps Lucene/Hibernate have a document with
their consistency requirements that we can start from?

One more thing I want to try with the current document is to switch
heading levels to make the different scenarios more prominent and the
different configurations less so - right now I have a lot of links
from one configuration to another. Radim was suggesting a summary
table with just a checkmark indicating if the cache stays consistent,
I'll have a go at that as well.

>
> Just for the sake of an example, the "limitation" pointed out of when
> using an Invalidating Cache with a shared cachestore, that invalidated
> entries might return from the cachestore seems a critical concern to
> me.

Yes, this looks very similar to the L1 invalidation problems that Will
fixed with his L1WriteSynchronizer - after all, the L1 cache is just
like an invalidating cache. But you missed the bigger (I think)
problem with a read operation undoing a write even in local mode :)

At first I wanted to create issues in JIRA for all the new problems
that I was seeing, but I wasn't able to keep up for long... As you
read it, feel free to add a TODO when you see something that's obvious
to you (or even better, add a link to a new/existing issue).

>
> But again thanks a lot for writing this, great step in the always
> challenging direction of improvement!
> Sanne

Thanks Sanne!

>
>
> On 23 December 2014 at 13:38, Bela Ban <bban at redhat.com> wrote:
>> Added the link to the Berlin agenda. An overview by Dan on this would be
>> nice, so that everyone's on the same page. Please read the document
>> before the meeting
>> Cheers,
>>
>> On 23/12/14 14:16, Radim Vansa wrote:
>>> Hi guys,
>>>
>>> since not everyone is watching ISPN-5016, I wanted to spread the
>>> audience for $SUBJECT [1]. A few details need more attention yet, but
>>> this is really the most comprehensive information on Infinispan Cache
>>> API guarantees and I'd recommend anyone to spend the time to read this
>>> carefully (although it's not an one-coffee article).
>>>
>>> Thanks a lot, Dan, for compiling this.
>>>
>>> Radim
>>>
>>> [1]
>>> https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-Infinispan
>>>
>>
>> --
>> Bela Ban, JGroups lead (http://www.jgroups.org)
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev