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). > > Andy > > ----- Original Message ----- >> From: "Galder Zamarreño" <[email protected]> >> To: "infinispan -Dev List" <[email protected]> >> Cc: "Steve Ebersole" <[email protected]>, "John O'Hara" >> <[email protected]>, "Andrig Miller" <[email protected]>, >> "Jeremy Whiting" <[email protected]> >> Sent: Wednesday, September 19, 2012 2:48:37 AM >> Subject: Re: [infinispan-dev] Issue with cache blocks for local read-only >> cache >> >> This is code written in JBoss Cache days to deal with situations >> where putFromLoad might try to store stale data (if data is deleted >> in between a database read and putFromLoad being called). >> >> Indeed this can happen with read only data, and has nothing to do >> with clustering. >> >> The original issue is: https://hibernate.onjira.com/browse/HHH-3817 >> >> I'll check how this can be improved. >> >> Cheers, >> >> On Sep 18, 2012, at 4:55 PM, Sanne Grinovero <[email protected]> >> wrote: >> >>> There seems to be a single (global) reentrant lock which is >>> acquired >>> on any put; I don't know much about the module design, but there is >>> a >>> comment close to the lock acquisition mentioning a need to flush an >>> operations queue to avoid a deadlock. >>> Could it just make sure to reorder keys, so that deadlocks are >>> avoided? >>> >>> On 18 September 2012 16:26, Manik Surtani <[email protected]> wrote: >>>> Agreed. >>>> >>>> This locking appears to be in the 2LC integration code to guard a >>>> local >>>> collection though - there must be better, non-blocking ways to >>>> guard this - >>>> if it is needed at all for RO entities. >>>> >>>> - M >>>> >>>> On 18 Sep 2012, at 15:18, Andrig Miller <[email protected]> >>>> wrote: >>>> >>>> What I find interesting, is that in this use case, READ_ONLY >>>> concurrency >>>> strategy and a local cache (no invalidation and no replication), >>>> there is no >>>> need to do any locking. >>>> >>>> If we can get to a solution without any locking that would be >>>> ideal. >>>> >>>> Andy >>>> >>>> ________________________________ >>>> >>>> From: "Manik Surtani" <[email protected]> >>>> To: "Ståle W. Pedersen" <[email protected]> >>>> Cc: "Galder Zamarreño" <[email protected]>, "John O'Hara" >>>> <[email protected]>, "Jeremy Whiting" <[email protected]>, >>>> "Andrig Miller" >>>> <[email protected]>, "Steve Ebersole" <[email protected]>, >>>> "infinispan-dev" <[email protected]> >>>> Sent: Tuesday, September 18, 2012 8:13:43 AM >>>> Subject: Re: Issue with cache blocks for local read-only cache >>>> >>>> >>>> Looking at your profiler snapshot, these locks are in the >>>> Hibernate 2nd >>>> level cache implementation for Infinispan. Galder, any ideas? >>>> >>>> - M >>>> >>>> On 18 Sep 2012, at 13:43, Ståle W. Pedersen <[email protected]> >>>> wrote: >>>> >>>> hi galder and manik, sorry for sending this mail to so many, but >>>> we've ran >>>> into a issue that prevents us from further scaling of the >>>> specjenterprise2010 benchmark. >>>> >>>> so when doing specjenterprise2010 benchmark testing we've seen a >>>> lot of >>>> blocks caused by the entity/query cache. we've been testing with >>>> only >>>> caching a simple entity bean that's read-only and queries related >>>> to this >>>> entity (selects). >>>> >>>> here is a screenshot of the hotspot >>>> found:https://dl.dropbox.com/u/30971563/specjent_block.png >>>> >>>> here is the standalone.xml: >>>> https://dl.dropbox.com/u/30971563/standalone-full.xml >>>> >>>> here is the orm.xml: >>>> https://dl.dropbox.com/u/30971563/order_orm.xml >>>> >>>> what we don't understand is why there are so many puts into the >>>> cache for an >>>> object that is marked as read-only. when we're testing without >>>> caching we do >>>> not see any blocks. >>>> >>>> any help/ideas would be great. if anyone want a jprofiler snapshot >>>> of the >>>> run, let me know. >>>> >>>> regards, ståle >>>> -- >>>> JBoss Performance Team Lead >>>> JBoss by Red Hat >>>> >>>> >>>> -- >>>> Manik Surtani >>>> [email protected] >>>> twitter.com/maniksurtani >>>> >>>> Platform Architect, JBoss Data Grid >>>> http://red.ht/data-grid >>>> >>>> >>>> -- >>>> 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 >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Galder Zamarreño >> [email protected] >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
