AOP Cache
This topic is in response to a recent thread on TSS.
I know I'm definately going to get flamed and such on how the caching works for 1st iteration, but hey, its usable.
Requirements:
1. The classes of Replicated/ACID objects must be marked for field interception by using in xml
2. Those objects in object graph that are not instrumented for field interception will not have their state transactional
3. System classes cannot be instrumented so fall into the category defined in #2 with the following exceptions:
- anything that implements java.util.Set, Map, or List. The AOP cache generates a proxy object for these types of Classes and reinserts these proxies in the object graph when the POJO is inserted into the cache
If you have:
class Person
{
public String name;
public int age;
public HashMap hobbies;
}
and do:
Person person = new Person();
String name = "Bill";
person.name = name;
HashMap hobbies = new HashMap();
person.hobbies = hobbies;
cache.put("bill", person);
Person cachedPerson = cache.get("bill");
the follow is applicable afterwards:
person == cachedPerson
person.name == name
although:
person.hobbies != hobbies
This is because a proxy is put in place for the collection.
As far as system classes:
Well, this kind of sucks for mutable system classes, but that is the limitation with the first release of the AOP cache. We're investigating other ways to deal with System classes, here are some things we're looking at:
1. Expand the Proxy approach done with Map, Set, and List
2. Javassist, the bytecode library under JBoss AOP, allows you to replace the name of one class with another. So, in Foo.class we could replace all allocations of java.util.Date with org.jboss.Date where org.jboss.Date would inherit from java.util.Date and would be instrumented with dynamic interception hooks.
3. Precompile our own java.util.* library and put it in the bootpath. This is illegal as regards to the JDK license