TreeCacheAOP features

[washeeq]

Hi,
I am evaluating your TreeCache and have three questions so far:
1) I want to use TreeCacheAOP and I do not need persistent cache. In doc is written that eviction policy for TreeCacheAOP can be used only with CacheLoader. It seems to me that there is no way how to automaticaly remove data from AOP cache. I have to explicitly call removeObject otherwise the object will be in cache all the time (either in memory or in persistent storage). So it leads to situation where persistent storage grows over all limits when I do not call removeObject on every object in cache. Is there any way how to make TreeCacheAOP stable in size?

2) Can I mark some fields to be not cached? Suppose that cached object can have associated some large lists of data which are not interesting for me in certain circumstances so I don't want them to be managed by cache. When I use TreeCache I can implement my own serialization which omits such filds, but how to achive this with TreeCacheAOP?

3) As I understand, isolation level for entire cluseter is efectivelly READ_COMMITED, am I right?

Thank you for reply, sorry for my english.

[ben.wang]

1. In general, TreeCacheAop only has advantage is your pojo has long life time. So most of the time I think issuing removeObject explicitly is not a problem. But yeah, I agree that it is still an issue. I just didn't have good solution. But there is a plan to refactor it in 2.0 due in 4-5 months.

2. This is also in the todo list using annotation. I am shooting for 1.4. One other option is you can mark it transient (althgouhg it is sort of ad hoc).

3. Yes.

[washeeq]

1. In general, TreeCacheAop only has advantage is your pojo has long life time. So most of the time I think issuing removeObject explicitly is not a problem. But yeah, I agree that it is still an issue. I just didn't have good solution. But there is a plan to refactor it in 2.0 due in 4-5 months.

2. This is also in the todo list using annotation. I am shooting for 1.4. One other option is you can mark it transient (althgouhg it is sort of ad hoc).

3. Yes.

Thank you Ben for prompt response. I found another one thing which is not clear for me. In 1.3.0 when using invalidation I need a method which adds object to cache, but (unlike put) does not trigger invalidation in other cluster members. I want to use this method when adding unchanged object (e.g. read from DB) to my local cache member.
I understand I can use scenario with CacheLoader to achive this, (is uses exactly this approach - adding data to cluser without invalidating), but we want to make cache light-weight without any other persisting layer.
The method(s) I am looking for would have following contract:
"Store data to cache (to my local cluster member) in the way like put, but do not invalidate this data in all other cluster members. It is my (developer's) responsibility, that data is not changed and the cluster cache is consistent."

It seems to me that when using invalidation, concrete data are present only in one cluster member which made the last put. Ofcourse when I am not using CacheLoader.

Thank you in advance,
Washeeq

[washeeq]

Wow, I found Option parameter in put method now. When I set cacheModeLocal to true, is seems that I get the desired behavior! Object is stored to memory and leaves other cluster members untouched. Cool. Is this correct usage? Does it have any side-effects I should know about?

I think you JbossCache guys are pretty smart :o) but why is this feature not mentioned in documentation?