On 24 Sep 2012, at 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. Yes, we're analysing the 2LC impl as well as Infinispan. > 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. ISPN-506 will only help in the clustered case. And SpecJ - and most other use cases - are not clustered. Maybe we need two 2LC implementations, one for clustered and one for non-clustered use? There are a lot of unnecessary locks that can be removed in the local case. Sanne and I were having a chat about this yesterday. - M -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
