Refactoring of object graph model in TreeCacheAop
ben.wang Aug 4, 2005 7:13 PMRecently I have been busy trying to build couple of more "real life" use cases for JBossCacheAop. The whole goal is to write an article promoting it! There are many possbilities after talking to people that are using it. But I have settled on two use cases both involved network management. They all have complex circular and multiple reference properties. In addition, heavy use of Collection classes (liek List) is also needed.
So that gave me a chance to fix couple problems in Collection class proxy support. But now I have run into a fundamental problem of the underlying object graph model. Previously, we use JBossInternal node to re-locate pojos that are multiple referenced. Here are the pros and cons:
Pros-
1. It is more "canonical". Meaning all the parent pojos of that shared object see the same tree under JBossInternal.
2. Locking can be applied in a more consistent manner
Cons-
1. Circular and multiple reference interaction is complicated becuase of relocation.
2. Relocation of pojos are expensive.
On the other hand, if we don't use JBossInternal, we will simply keep track of reference counting within the original pojo. Here are the pros and cons.
Pros -
1. No need for re-location. So it is efficient.
2. No need to distiguish between circular and multiple references. Their interaction is vastly simplified.
Cons -
1. It is not canonical. I.e., the location of the shared pojos depends on the order of the parent pojo get put into cache.
2. Locking behavior can be inconsistent depending on where the referenced object resides.
3. Overwriting of an existing pojo that is still multiple referenced will need to throw exception.
Anyway, because the obstacle is Cons #1 in the first JBossInternal model, I am now leaning toward the second solution of keeping the refernce counter of the original pojo. Then to solve the problems, we will:
1. To address the canonical problem (and thus the resulting locking issue), a user is advised to put the referenced pojo into cache first, e.g., cache.putObject("/shared", sharedPojo), although this is still not totally desirable.
2. To address overwriting of exsiting shared pojo that holds the reference counter, we will throw an exception if attempted. So a user is warned. Again, this is not a complete solution because a user may need to know the alternative. But we shall just treat it as a limitation now.
Any sgguestion?
-Ben