On Tue, Dec 23, 2014 at 9:39 PM, Sanne Grinovero <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
