Hi. Just came upon JBoss Cache today, and it looks like a great piece of software. And just what I need. Well, actually, *almost* just what I need. Unfortunately, it looks like an earlier architecture decision that was made with the product will actually make it very difficult to do what I want to do, and I'm a bit puzzled by the decision. I'm talking specifically about the architectural choice of arranging the cache as a tree instead of a map. As per the docs: http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc... "The first version of TreeCache was essentially a single HashMap that replicated. However, the decision was taken to go with a tree structured cache because (a) it is more flexible and efficient and (b) a tree can always be reduced to a map, thereby offering both possibilities. The efficiency argument was driven by concerns over replication overhead, and was that a value itself can be a rather sophisticated object, with aggregation pointing to other objects, or an object containing many fields. A small change in the object would therefore trigger the entire object (possibly the transitive closure over the object graph) to be serialized and propagated to the other nodes in the cluster. With a tree, only the modified nodes in the tree need to be serialized and propagated. This is not necessarily a concern for TreeCache, but is a vital requirement for PojoCache (as we will see in the separate PojoCache documentation)." Now I understand this explanation, and how it benefits PojoCache. However, the comment that "a tree can always be reduced to a map, thereby offering both possibilities" doesn't really seem correct for my specific case and, unless I misunderstand, having the cache set up as a tree will make it extremely difficult or impossible for me to use JBoss Cache for what I want to do. Let me elaborate. What I would like to do is to use a JBoss Cache Cluster as a memory cache front for a database. i.e., I want the cache to hold individual records from the DB, indexed by key, and when I write record updates to the cache I want them to get flushed down to the DB. Seems like a pretty straightforward application for the cache + CacheLoader combo. And I see that by using one of the various provided CacheLoaders, it should be easy to do that using either a JDBC SQL database, a Berkeley DB JE database, etc. as the backing store. Except it's not. Unless I misunderstand, there is no (easy) way for me to use the TreeCache get and put operations to read/write individual records. This is because the TreeCache doesn't work on key/value pairs, but rather fqn/key/value tuples. So when I look at the code for, say, BdbjeCacheLoader, instead of it writing key/value pairs out to the BDB database, as I might expect, it instead stores pairs of fqn/map<key,value>. Storing things this way causes several problems with my intended approach: 1) Let's say I try to use my internal "table name" as the fqn, and my record's key as the key. The problem here is that the implementation seems to make calls to public Map get(Fqn name), and this would wind up returning the *entire* contents of my table (potentially millions of records!) in a single map. So this won't work. 2) Let's say I try to use "/" + my internal "table name" + "/" + my record's key as the fqn, and a bogus fixed string constant for the key on the put operation. This would allow me read/write individual records, but a) this is a hacky way to use the API, and b) the BdbjeCacheLoader would wind up each time returning a newly instantiated map with 1 record in it, which is very inefficient. So given the TreeCache's architecture, there doesn't seem to be any way to use the existing CacheLoaders to easily do what I want. Am I wrong? Am I misunderstanding anything about the architecture here? And, most importantly, is there any non-complex way for me to use JBoss Cache to serve as record-level front-end cache to a database like I'm trying to do? TIA. (And hopefully someone's listening out there!) :-) DR