On Sep 24, 2012, at 12:27 PM, Manik Surtani <ma...@jboss.org> wrote:
> > On 24 Sep 2012, at 11:01, Galder Zamarreño <gal...@redhat.com> wrote: > >> >> On Sep 21, 2012, at 3:43 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> >>> On 20 September 2012 17:38, Andrig Miller <anmil...@redhat.com> wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Galder Zamarreño" <gal...@redhat.com> >>>>> To: "Andrig Miller" <anmil...@redhat.com> >>>>> Cc: "Steve Ebersole" <st...@hibernate.org>, "John O'Hara" >>>>> <joh...@redhat.com>, "Jeremy Whiting" >>>>> <jwhit...@redhat.com>, "infinispan -Dev List" >>>>> <infinispan-dev@lists.jboss.org> >>>>> 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 <anmil...@redhat.com> >>>>> 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. ^ I disagree. It might help with the edge case highlighted in https://hibernate.onjira.com/browse/HHH-3817 which happens in a local cache. > 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 > ma...@jboss.org > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
