$Id: NewAopObjectGraph.txt,v 1.2 2005/08/08 23:43:23 bwang Exp $

This is a new design of TreeCacheAop to handle object graph. Previously,
we use JBossInternal to relocate any object that are multiple referenced.
While it is more canonical, it suffers from speed loss (need to move and 
put), and also complication when there is interaction between cicurlar
and shared references. Case in point is the TestNode and NodeManager
test cases.

The new solution is to revert back to the althernative by not moving the
referenced node to JBossInternal. Instead, every object that is referenced
will maintain a reference count. No more need to do a relocated.

AFAIK, there are two potential problems to this approach though:

1. The resulting cache is not canonical, .e, put "joe" before "ben" will
impact the behavior of the shared address, especially during locking.
But this problem can be mitigated by putting "addr" first so it will then
becomes canonical.

2. Remove "joe" from the cache won't remove addr if it is located there since
it is still multiple referenced! Solution to this we throw an exception if we
attempt to remove a fqn but that still has pojos residing in there. But long
term solution?
We will create a FqnNotEmptyException
for this.

Note that with solution 2, overwriting an existing will also need to check
if after remove, it still has child pojo or not.

In addition, during final step of remove, we will need to do explicit remove
instead of brute force. This may be ok anyway.


Another approach initially proposed by a user (Tim Wundke) is to JBossInternal 
all the way. That is, every cache put will map pojo into JBossInternal 
recursively.  We only maintain ref counter under the the user-specified fqn. 
All pojo and thei sub-pojos are stored in JBossInternal.

Pros:

1. Ref counting is straightforward. 
2. There is no issue of locking 
3. Over-writing of current existing pojos will be allowed.

Cons:

1. Mapping into JBossInternal with pojos will become flat. We don't use the tree
structure that comes with TreeCache
2. Eviction policy based on region will be broken. We will need pojo-based 
eviction that is a total departure of current eviction policy.
3. What about non-Aspectized objects like Collection and Serializable? We won't
have a CacheInterceptor to track them so we can't re-locate them to JBossInternal.

