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@jboss.org>
To: "Ståle W. Pedersen" <spederse@redhat.com>
Cc: "Galder Zamarreño" <galder@redhat.com>, "John O'Hara" <johara@redhat.com>, "Jeremy Whiting" <jwhiting@redhat.com>, "Andrig Miller" <anmiller@redhat.com>, "Steve Ebersole" <steve@hibernate.org>, "infinispan-dev" <infinispan-dev@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
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
Platform Architect, JBoss Data Grid