"manik.surtani(a)jboss.com" wrote : | * put/remove and replaceAll - makes sense, but may be a case of "change for change's sake" since most cache loader impl's would actually do something like what you suggested internally anyway. | 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. When I worked on the Amazon S3 CacheLoader I felt like having to download data on the client side for those operations was unnecessary overhead--most of the time. If the local cache already had loaded the node data, then really all the local cache should do is perform the data modification on the local node map and do a "replaceAll". I suppose each CacheLoader could check if a node was loaded through the CacheSPI handle it has, but really this could be done uniformly in the CacheStoreInterceptor. You could always make a new interface in 3.0 like OptimizedCacheLoader with a "replaceAll" and detect it. "manik.surtani(a)jboss.com" wrote : | "genman" wrote : | | Also, I'd take a look at how Hibernate uses JBoss Cache 2. It seems there's a bunch of "util" methods that might make sense to carry over. One thing that comes to mind is the use case of storing a single item in a Node. Maybe create a "key" singleton object? | | Something like this already exists - JBCACHE-1082. Needs to be worked in to the codebase, properly profiled and optimised though. It'd be nice if there was a canonical key object though. Something that could be optimally serialized and deserialized as a single byte using the existing CacheMarshaller. Maybe like have something like: | public interface Node { | | private enum Key { KEY; } | | /** For nodes that store a single value, use this as the key */ | Object key = KEY; | | ... node methods here | } | "enum" is good for creating singleton instances. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156428#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...