[
http://jira.jboss.com/jira/browse/JBCACHE-811?page=comments#action_12398381 ]
Manik Surtani commented on JBCACHE-811:
---------------------------------------
Backed this out from 2.1.x as the initial implementation was a major perf hog. It was
actually quicker to repeat the peek as and when necessary - mainly to do with the
map.put() and get() operations caching the relevant nodes in the InvocationContext, keyed
on Fqn (which is expensive when it comes to equals() and hashCode())
Use InvocationContext to avoid multiple searches for a node
-----------------------------------------------------------
Key: JBCACHE-811
URL:
http://jira.jboss.com/jira/browse/JBCACHE-811
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.2.0.GA
When an interceptor finds a node, why not throw it in the InvocationContext or something
similar and pass it through the stack that way? Subsequent calls to find the node can
check the context first before walking the cache tree. Saves redundant walking of the
tree.
We'd need to think very carefully about this, as it exposes 2 paths to access a node
-- from a thread's context and from the tree. Need to ensure concurrent threads
always access the same node object for a given Fqn.
(Side thought -- perhaps disable this for weak isolation levels where the locking
behavior in the interceptors make it possible to end up w/ 2 concurrent nodes for the same
Fqn).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira