[infinispan-dev] Issue with cache blocks for local read-only cache

[Sanne Grinovero]

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 <manik at jboss.org> 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 <anmiller at redhat.com> 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" <manik at jboss.org>
> To: "Ståle W. Pedersen" <spederse at redhat.com>
> Cc: "Galder Zamarreño" <galder at redhat.com>, "John O'Hara"
> <johara at redhat.com>, "Jeremy Whiting" <jwhiting at redhat.com>, "Andrig Miller"
> <anmiller at redhat.com>, "Steve Ebersole" <steve at hibernate.org>,
> "infinispan-dev" <infinispan-dev at lists.jboss.org>
> 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 <spederse at redhat.com> 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
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev