JBoss cache architecture question
by David Rosenstrauch
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
17 years
- 2
- 2
- ← Newer
- 1
- Older →