Caching in Clearspace usually refers to the back-end distributed memory cache technology, backed by Oracle Coherence. In addition, there is a page-level cache web filter, and some render-layer filtering, but this document does not address these.
There are 2 use cases for developers:
Coherence Cache Configuration Documentation
You want to cache objects in order to keep them in memory to avoid making a database read. The Coherence cache is distributed memory cache, which means any server in your cluster will be able to read it from memory. It's significantly faster to use the cache as opposed to a database call. Ideally you want to make all of your persistent database objects cached. If you don't read an object frequently it may not be necessary to make it cacheable. However, experience shows that data has a tendency to become used more frequently over time and most things end up needing to be cached in the end.
Yes, if you'd like to maintain server-side state across a cluster, a cache is the best place to do that. We use that to track Document edit sessions, form tokens, login presence, etc.
This can be a complex debugging process. Ideally, you'd step through the code in a debugger. You could also check for database calls; if they are being called repeatedly you can infer the object isn't being stored. You can access the contents of the cache through the Coherence mbean (see Oracle site) or Coherence command line tools.
You need to implement 2 interfaces: com.jivesoftare.community.cache.Cacheable, and optionally com.tangosol.io.ExternalizableLite. Next, you don't want to hold onto object references of other objects you don't explicitly own. E.g. you don't want to store a User object, you'd want to store the user id as a long. In general try to hold Strings and primitives.
Generally, when you are creating a new database persisted object type you'd want to create a new cache devoted to it. See the above answer about maintaining server state.
NOTE: you don't write any new code to create a new cache, Coherence takes care of that for you if you define the cache in these config files.
Cache implements the Map interface. The common idiom in backing a database call with a cache is to:
public void loadObject(long objectId) {
Object myObject = cache.get(objectId);
if (myObject == null) {
myObject = loadObjectFromDb(objectId);
cache.put(objectId, myObject);
}
return myObject;
}
public void saveObject(Object myObject) {
saveObjectToDb(myObject);
cache.put(myObject.getId(), myObject);
}
Since Clearspace uses Spring to instantiate the managers it's instantiating and injecting the Cache implementations to the managers. See the spring-cacheContext.xml file to see the Clearspace cache definitions.
Yes. Through the cache-config.xml file you deploy with your plugin. See the plugin documentation.
Generally, you want to make defensive copies of objects you retrieve from the cache, i.e. cloning objects before returning them. If you don't you run the risk of corruptiung data in the cache, e.g. if a form fails validation and partially edits the data. Then the data in the cache can get out of synch with the database. Generally you want to write to the cache at the same time you're making the database call, most often in the same update method in the manager.
In Clearspace the pattern is to manage the interactions between the cache and persistence concerns in the manger layer. The Manager implementaitons are where you should be putting cache access logic.
Functionally, there should be no differences. Behind the scenes, you're using different implementations; the single node implementation is optimized so that it doesn't make the network calls to maintain the distributed cache.