Customer reported an issue where an OPTIMISTIC 1.4.1.SP3 didn't scale well when
Hibernate was caching a large # of instances of an entity. All entity instances are
stored in a child nodes directly under a base node for the entity. They were caching tens
of thousands of instances and saw put() performance drop off dramatically as more
instances were added.
I believe the problem is that as the workspace is set up for a put, the base node for the
entity is copied. This involves making a copy of the children map. That map copy
operation won't scale.
One solution is to increase the depth of the tree. Customer tried adding 3 more levels
below the entity base. This leads to problems with eviction though (all those added
"structural" nodes affect eviction algorithms).
One concept I've been thinking about today is trying to avoid the children map copy.
Half baked thought:
1) For optimistic cache, regular base node uses a subclass of ConcurrentHashMap for its
children map.
2) Subclass exposes listener registration methods. When a WorkspaceNodeImpl is created,
its registers as a listener on the base node's children map. Unregisters as part of
workspace reconciliation.
3) When the put or remove methods are called on the base node's map, those methods are
overridden to send notification events to any registered listeners.
4) WorkspaceNodeImpl tracks any events and uses the info to present a consistent image of
the original children. E.g., if a "remove" event is received, the workspace
node caches the removed node and uses it to satisfy any internal get calls. If an
"add" event is received, the workspace node caches the key to ensure that any
get call for that key ignores the base cache.
This might be full of holes or more trouble than it's worth, but wanted to throw it
out there.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059749#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...