-
1. Re: how about an update bela?
The cache is still evolving. Check out the TreeCache.doc in the jboss-head/cache/docs directory and the TreeCache.java class itself as a starting point. The doc is somewhat moot as I have changed certain things etc.
Okay, here's what I have so far:
- A tree structured cache with puts and gets
- A cache can be transient, repl-async and repl-sync. Transient cache doesn't replicate modifications. Repl-async replicates modifications asynchronously, so eventually all caches will have the same contents. Repl-sync replicates in lock-step, so when you return from a put() you know that all caches already have the same contents for the key you added/modified.
- If a modification is made inside a transaction, then we have acidity. Changes are visible only after commit. I currently use pessimistic locking (should be done by EOD today 4/18/03) to ensure serializability. I have optimistic locking on the todo list.
- How does this relate to AOP ? I intend to instrument values you put into the cache, e.g. put(key,val) and val is a graph, we need to recursively 'spike' all objects rechable from val (including val). This mean, add an interceptor for each node in that graph. On insertion we break the object into the constituent parts (fields, objects) and map them onto the tree. Each interceptor intercepts "get*" and "set*" methods. On get*() it returns the cached attribute, on set*() it updates the cache and forwards the invocation.
- So AOP will allow me to simply put an object in the cache and the cache takes care of the rest.
- So first stage is replicates transactional cache, and second stage is AOP on top of it. However, you will always be able to use a tree-structures replicated cache as a building block without AOP if you want to.
- Bill and Marc believe that acidity (locking, versioning etc) should all be in an interceptor. I'm somewhat skeptical, but need to look into the issue some more. For instance, a locking interceptor sees only the object it is supposed to lock/unlock. But when you're in a tree, and you lock an object, someone else may want to remove the entire subtree in which the object is ocated, so locking needs to consider more than one object.
- Again, my intention is to provide a fast&efficient, low-overhead replicated cache. Bill and I will talk some more, and maybe you really *can* move everything into interceptors. At that point I could simply disable my own locking and acidity (I can already do it now) and take Bill's AOP interceptors.
Bela