Best use of Jboss Cache Implementation

[lords_diakonos]

I am migrating our app from OSCache to Jboss Cache.

In OSCache we had a singleton CacheAdmin interface with methods for put, get remove etc... It would stick all the objects in a single cache. The put method signature looks like
put(String key, Object content, String[] groups);

You can then flush based on group, key etc...

So I have 2 questions.

1. Is having a singlton Cache in jboss cache where all objects get cached ok? or is this bad practice?

2. Can I use the FQN's to accomplish what the groups did? actually what would the best way to do this be is what I am asking.

[genman]

In JBoss Cache, usually you use FQN as the "key" and you'd put the content and groups under a single Node instance.

Using a single instance is okay as long you'd like the locking, replication, and cache loading behavior to be the same for all data in that cache.

[lords_diakonos]

Uhmm by group though I didn't mean server's (buddies) I meant an array of Strings which work as a way of removing etc... all objects with that group. Like a tag. OSCache uses that instead of the FQN but it takes a String[] of them.

So I am not sure what the best practice way to do this with Jboss Cache is. It seems each object can have a single FQN. it may get built as a b tree so a/b/c
but this is a little different.

In OSCache say I have 2 objects. One in String["c"] group and another in String["b", "c"] group. I can say cache.remove("c") and both objects would be removed.

Our primary cache singleton interface has methods like this on it.

[manik]

Yeah, there is no similar concept of "groups".

Fqn is basically a path in a tree structure. JBoss Cache uses a tree as a data structure, and stores key/value pairs in nodes in the tree.

Simplistically, if you did not care about any optimisations around the tree structure, you could just create Fqns based on the yupe of data you are storing, sort of like namespaces. E.g.,

cache.put("/org/mycompany/customerdata", "customer1", c1);

Now since all locking and replication happens on a per-node basis, you may optimise further to do something like:

cache.put("/org/mycompany/customerdata/customer1", "customer1", c1);

so that each node contains information pertaining to a single entity.

Regarding singletons, it is a valid pattern, only we don't implement it internally and prefer users to do this themselves based on their environment e.g., an IoC framework may have it's own mechanism of creating, maintaining and injecting singletons, a Java EE environment may use JNDI, or simplest of all, you may create a CacheSingleton class with a single static getInstance() method.

HTH,
Manik