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