"aditsu" wrote : I noticed that UnversionedNode.getData() is taking a lot of time in my app. Then I saw that it actually creates a new HashMap, calls getKeys, then gets the value for each key separately and puts it in the map. | Every single cache.get(fqn, k) separately fires the whole chain of interceptors... transaction, locking, notification and whatnot. Couldn't it do it only once, on the node as a whole? Yes, this should delegate to Cache.getData(Fqn). Corrected in CVS. "aditsu" wrote : | Also, I found a little gem in LockMap.java: | | // a CopyOnWriteArraySet is HUGELY inefficient since MANY LockMaps are created and are frequently read from. Until we have a better impl ... | private final Set readOwnerList_ = new CopyOnWriteArraySet(); | I added this comment, and then toyed with a striped-lock/CHM based implementation of a ConcurrentHashSet (see o.j.c.util.concurrent.ConcurrentHashSet) and while this was more performant than a CopyOnWriteArraySet in many places in the cache, it wasn't so in the LockMap. After profiling, the LockMap was actually quicker with the CopyOnWriteArraySet. Anyway, we do have plans to overhaul the whole concurrency/locking aspects of the cache, see http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheMVCC View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069584#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...