On 24 September 2012 11:01, Galder Zamarreño <[email protected]> wrote: > > On Sep 21, 2012, at 3:43 PM, Sanne Grinovero <[email protected]> wrote: > >> On 20 September 2012 17:38, Andrig Miller <[email protected]> wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Galder Zamarreño" <[email protected]> >>>> To: "Andrig Miller" <[email protected]> >>>> Cc: "Steve Ebersole" <[email protected]>, "John O'Hara" >>>> <[email protected]>, "Jeremy Whiting" >>>> <[email protected]>, "infinispan -Dev List" >>>> <[email protected]> >>>> Sent: Thursday, September 20, 2012 6:48:59 AM >>>> Subject: Re: [infinispan-dev] Issue with cache blocks for local read-only >>>> cache >>>> >>>> >>>> On Sep 19, 2012, at 4:20 PM, Andrig Miller <[email protected]> >>>> wrote: >>>> >>>>> Yes, I can see how that can happen, if the data is deleted from >>>>> outside the application. >>>> >>>> ^ The issue does not only happen if the data is deleted outside the >>>> application. As indicated in >>>> https://hibernate.onjira.com/browse/HHH-3817, this can happen with >>>> two competing transactions. >>>> >>>>> If you cache something as READ_ONLY, and it gets deleted, that >>>>> doesn't fit the definition of READ_ONLY though. You are using the >>>>> wrong cache concurrency strategy. >>>>> >>>>> Even that issue outlines the scenario where the collection is >>>>> updated, which means its not a READ_ONLY. >>>> >>>> I think the update is irrelevant here. The issue is related to >>>> putFromLoad + remove, which both AFAIK, are allowed in READ_ONLY >>>> (remember that we had the discussion on whether remove should be >>>> allowed in a READ_ONLY cache: >>>> https://hibernate.onjira.com/browse/HHH-7350). >>>> >>> >>> Yes, remove can be done, its just update that matters to READ_ONLY. One >>> thing I thought about was I thought we were using MVCC for this stuff. Any >>> transaction that reads from the cache, while something is being >>> added/removed, should be reading the read consistent image, and should >>> never wait on a lock, correct? We see all the threads in our thread pool >>> sitting in a blocked state based on this locking. > > I'm not 100% sure which locking are you talking about, but if you're refering > to the lock in https://dl.dropbox.com/u/30971563/specjent_block.png, that's > related to the 2LC integration, not Infinispan itself. > > If you're talking about threads waiting for a lock somewhere else, please > provide more details. > > I have some short-term ideas to improve the 2LC integration code, but I wanna > check with Brian first. > > Long term, I think https://issues.jboss.org/browse/ISPN-506 will be necessary > to provide a lock-free solution to these edge cases in such way that 'newer' > removes cannot be overridden by 'old' putFromLoad calls. However, I'm > intrigued by the fact that JBoss Cache OL had the capability of being given a > version externally, but the 2LC code for JBoss Cache OL still used this > PutFromLoadValidator logic. Again, something I need to check with Brian. > >>> >>> That really shouldn't be happening with MVCC. >> >> This would be correct, if only Infinispan would support MVCC, but >> that's not the case today. > > Sanne, don't understand why you say that. > > In Infinispan, we make copies when writing so that existing transactions can > carry on working with a read value without problems and no locking.
We had a discussion a while back - I believe on this same mailing list - about the "interpretations" of MVCC. At some point we realized I had a different expectation of how things where working, as for the "MVCC" keyword I was expecting multiple *versioned* entries to be stored, to easily allow for features like ISPN-506, ISPN-1116, eventual consistency, etcetera. It turned out there was quite some confusion around the MVCC term being tossed around, and we agreed that what Infinispan does today is not what is usually defined as MVCC, and that we should stop calling it that way as it generates confusion: Infinispan does not implement MVCC as it's defined for example on the wikipedia, and as I think Andy was expecting in this context. I also highlighted the need for versioned null markers, not only to make sure a removal (or write of a null value) would not be undone by a command reordering race, but also to cache the fact we know a specific key is null, so that a remote node can reply with "well known as null" so that we don't try loading it over and over when all nodes just know the key is not mapped. I also wrote some related proposals for CAS improvements in a single command: not having to send the actual value to evaluate for the comparison operation.. there are many reasons for which we need a real MVCC based core. Finally, I have been asking for a way to provide "consistent reads" across multiple keys several times, as it's very useful to better scale the Lucene integration: to implement something like that, I'd need real MVCC capabilities. Cheers, Sanne _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
