[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-450) Create a pure pojo-based eviction policy

[Ben Wang (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBCACHE-450?page=comments#action_12339739 ] 
            
Ben Wang commented on JBCACHE-450:
----------------------------------

After some further thinking, I conclude that eviction is really not well suited in PojoCache. Again, it will have to run as part of passivation. Here is why.

If we use eviction only to evict the pojo then:

1. When evicted, the cache content will be empty (i.e., no long available). What happens to the interceptor? Do we remove it as well or not? If we keep the interceptor,  what happens when the pojo is accessed again, e.g., pojo.getAge()? It will return null since the cache content has been evicted already.

2. However, if decide to remove the corresponding iterceptor, then pojo.getAge() will return correctly. However, pojo.setAge(21) won't be intercepted by the cache interceptor. It will be just a regular pojo operation. This is a semantic change that user won't be aware of.

3. For pojo-based eviction, if a sub-object is refereshed, we will need to refresh the corresponding parent object as well. E.g., if address is refershed, then Person needs to be refreshed (i.e., no evicted). We need to take care of multiple references as well. We can do this in 2.0 since we keep track of like of parent object from the sub-object. Nonetheless, it is not as straightforward.

4. What happens at the remote node if it is a passive node (e.g., only failing over purpose). Then the pojo won't be evicted since officially there won't be one yet (untill the user do cache.find(id))

So I think the best way is go with passivation. If we use passivation, we can use the current cache node-level eviction policy. We really don't care about the pojo level since from PojoCache point of view, the fqn value is always available, e.g., when I do a pojo.getAge(), behind the scene, the cache loader will retrieve the value associated with the age item, e.g., cache.get(id, "age"). This way, we are totally transparent.

Couple things to take notice though:

1. When it is passivated, if the pojo becomes orphan (i.e., no one is referencing it anymore), GC will kick in. Originally, the pojo reference is also stored under AOPInstance (as a strong reference) but now AOPInstance has been passivated already (and the reference field is a transient modifier), so GC can freely to collect the pojo instance. No problem in the vm.

2. The only problem though is what happens to the data in the cache loader store? Since the pojo has been GCed, most likely no one will use it (unless, I am using cache.find(id) again to resurrect it), we will need to come up a way to trim it or age out. We can have a separate timer thread to weed out the ageout items.

3. This is the scenario:

cache.attach("pojo", pojo);
pojo.setName("Ben");
...
// it is passivated

pojo.getName(); // no problem here

Pojo anotherPojo = cache.find("pojo");

then pojo != anotherPojo because getAopInstance() return nulls during find (becuase it is a transient field).

Can we come up a way to serialize the pojo reference but not replicating it? If somehow AopInstance contains non-transient pojo reference but AopInstance is stored as a local cache mode (e.g., doesnt replicate), then it is serializable but not replicatable. As a result, case solved.

If we can't, then everything will work fine actually, e.g., pojo and anotherPojo can do indepdent update and get. But only comparison of object identity (by reference) will fail.


> Create a pure pojo-based eviction policy
> ----------------------------------------
>
>                 Key: JBCACHE-450
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-450
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: POJOCache
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> The eviction policy module has been refactored in 1.3. We will need to refactor the pojo-based evitction policy as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira