[jboss-dev-forums] [Design of JBossCache] - Re: JBoss Cache Public API

[manik.surtani@jboss.com]

"genman" wrote : Removing type parameters seems like a good idea.

Agreed, but I'd want to see to what degree this will affect backward compatibility.  E.g., how many folk have written code to make use of this in 2.X.

"genman" wrote : 
  | Something to consider would be to change the Node interface to return live references, e.g. "Cache.getNode(x).getData()" would return a Map whose operations affect the in-cache state. So a "getData().clear()" would clear the node data. I'm not sure how well this would work. It may be poorly performing.
  | 

Could be poor performing if it has to be by way of a proxy map (which would then make calls up and down the interceptor chain to ensure locking, loading, etc.).  But I like the "usability" implications.

"genman" wrote : 
  | I created a "Caches" utility/factory object a long time ago that created java.util.Map instances backed by JBoss Cache and it'd be interesting if something like that were endorsed.
  | 

It (or something very similar) certainly will be in 3.X.  I think there is a lot of value in a "flat map" interface, especially since this plays into JSR107 nicely.

"genman" wrote : 
  | I would suggest changing the CacheLoader interface.
  | 
  | Remove these methods:
  | 
  |   |    Object put(Fqn name, Object key, Object value) throws Exception;
  |   |    Object remove(Fqn fqn, Object key) throws Exception;
  |   | 
  | These are low-performing operations on many CacheLoaders implementations.
  | 
  | Also I would remove
  | 
  |   |    void put(Fqn name, Map<Object, Object> attributes) throws Exception;
  |   | 
  | and replace the put operation with:
  | 
  |   |    void replaceAll(Fqn name, Map<Object, Object> attributes) throws Exception;
  |   | 
  | 
  | Remove methods that are redundant:
  | 
  |   |    void loadEntireState(ObjectOutputStream os) throws Exception;
  |   |    void storeEntireState(ObjectInputStream is) throws Exception;
  |   | 
  | (Though their removal is probably not critical.)
  | 

* 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.
* load/store state - this is needed to be able to stream state from one cache loader to another.  Deserializing everything and then calling replaceAll() may be unnecessarily expensive if the CLs can have an internal mechanism of working with the streams directly.

"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.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156246#4156246

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156246