"manik.surtani(a)jboss.com" wrote : "genman" wrote : | | The problem with "putAll" (and "put" and "remove") is that they require a storage read for every call. If you can get them to perform okay, then I don't really care. | | | | Why? I agree that such calls should be optimised by the Interceptors not to do a load if the state needed is already in mem (for the return value of a put or remove), but beyond that, why would putAll, etc. do a storage read? | I don't see why they do, but they do. For example, for FileCacheLoader, if erase is "false", which is called by "put(Fqn, Map)", then a read is made: | @Override | public void put(Fqn fqn, Map attributes, boolean erase) throws Exception | { | lock.acquireLock(fqn, true); | try | { | Map m = erase ? new HashMap() : loadAttributes(fqn); | if (m == null) m = new HashMap(); | if (attributes != null) | { | m.putAll(attributes); | } | storeAttributes(fqn, m); | } | finally | { | lock.releaseLock(fqn); | } | } | JDBC and all the other cache loaders are similar... I don't see why they should necessarily do a read for this operation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156881#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...