pin object in cache?

[saylor09]

I'm running with jboss-cache 1.2 (no minor number spcified in manifest so I'm guessing it might be 1.2.0). I'd like to be able to pin specific nodes in the cache. From what I can tell, there is no built-in (i.e. simply configurable at run time) way of doing this. I'm guessing that I would have to customize the eviction policy somehow.

I would like to know if there is a supported option for pinning certain nodes into the cache (perhaps in the latest 1.2.4?). If not, any pointers on where to look to make this kind of behavior happen would be most appreciated.

thanks

Scott

[manik]

You can get version info by running:

$ java -cp jboss-cache.jar org.jboss.cache.Version

Are you trying to pin down specific data nodes to specific caches in a cluster so they do not replicate across to other caches in the cluster?

[ben.wang]

Use eviction policy. Put your pinned data under one region, say, "/never_expires", and configure this region to never expire.

-Ben

[saylor09]

Thanks for the reply Ben.

I know that I can do this by defining a different region that has a specific never-expire configuration, but it's not quite what I'd like to do. Currently, I am using JBossCache as a means to store an object graph (i.e. not a collection of tree graphs). My caching needs require unique object representations. Any given object may be referenced by n number of objects. What I have essentially ended up with is a very flat tree (in TreeCache) where a single region contains all cached objects. I preprocess my nodes to replace references to other objects with pointers that essentially hold onto the FQN of the objects being referred to, and then i place those referred objects into their own node in this region. For example:

 /domaindata
 |
 ----------------------------------------
 | |
 /1234 /345
 number => "xasdf" name => "applicant: 1234"
 name => "case-foo"
 applicant => objectref("345")

I can grab any amount of data from the server based on a unique object id and then update any invalidated portions of the (client-side) cache without needing to worry about multiple representations (that might be under some nested tree)

Perhaps my intended use does not quite fit with TreeCache, but that's how I have it at the moment. I'm currently considering alternative implementations.

What I was really hoping to do was to be able to say something like "pin node 345". But if TreeCache treats regions and nodes in the same manner, then perhaps I could define "/domaindata/345" as a region and then set the configuration that way? However, can I easily change the configuration policy at runtime? It seems that the eviction policy is only derived from XML. I suppose I could add to this at runtime, but it looks like I'd have to restart the service to get this to take.

I could create a never-expire region and push things under that region when needed, but this means that my processing will have to include checks to see if any given node may be either under "/domaindata" or "/never-expire". I'd prefer not to add this overhead.

The one other alternative I thought of was to override the LRUPolicy/Algorithm somehow. But I'm guessing it would be better to update the runtime configuration somehow so that the nodes are not even processed for eviction (as they would be determined to never expire).

Scott

[saylor09]

Thanks for the tip, Manik. I ran "java -cp jboss-cache.jar org.jboss.cache.Version" and it says 1.2.

If need be, upgrading is not an issue.

Scott

[ben.wang]

If you are stoing object graph in the cache, have you considered using the pojo cache component (TreeCacheAop)? It has its own pojo based eviction policy that may meet your need.

-Ben

[saylor09]

Yes, I've looked at TreeCacheAOP but I don't think it will fit with my usage. I need to be able to lookup a specific object by it's unique id so that I can invalidate and update as needed. I am not using it in a replication scenario. I'm just using it as a simple remote client-side cache of data pulled from the server. I'm sending over DTO objects that contain the domain data, then I'm jamming it into TreeCache to cache it. If I have, for example, Case1 -> Person1, and Case2 -> Person1, will TreeCacheAOP resolve both Person1 references to the same object? To complicate matters further, these objects are not the actual domain objects but are only variations of value objects (DTOs to be more precise). I may have a bulk CaseDTO or a summary CaseSummaryDTO that represent the same object but contain differing amounts of data. This is probably the real kicker for not being able to use TreeCacheAOP right out of the box.

I'm essentially wrapping TreeCache with my own processing so that I can track invalidation logic and tie together the various DTOs to their associated domain object representations. My cache wrapper then listens for events about changes to the domain objects (via JMS). If client1 holds on to a cached Case1 object, and client2 modifies Case1. client1's cache will receive the event and mark Case1 as invalidated. If client1 asks for Case1, my cache wrapper will see that as a "cache miss" and refresh the data for Case1. Hopefully this makes some sense. :)

As there are certain domain data elements in the client application that are considered to always be there, I'd like to be able to mark specific nodes in the cache as non-expiring so we aren't processing extra cache miss operations (because the requested data may have been evicted). What nodes these are is not known until runtime.

BTW, I found an answer to my question about modifying the caching policy at runtime by searching around the forums a bit harder. It turns out this just isn't supported (yet). Thanks for not flamming me like some of the other jboss guys do in the other forums. I was a bit apprehensive about even posting anything to the jboss forums. :)

Scott

[manik]

"saylor09" wrote:

As there are certain domain data elements in the client application that are considered to always be there, I'd like to be able to mark specific nodes in the cache as non-expiring so we aren't processing extra cache miss operations (because the requested data may have been evicted). What nodes these are is not known until runtime.

Hmm, I suppose extending the LRUPolicy may help as a quick fix - extend it to ignore specific FQNs if you know which FQNs need to be pinned? Or have I misunderstood your use case?

"saylor09" wrote:

BTW, I found an answer to my question about modifying the caching policy at runtime by searching around the forums a bit harder. It turns out this just isn't supported (yet). Thanks for not flamming me like some of the other jboss guys do in the other forums. I was a bit apprehensive about even posting anything to the jboss forums. :)

:-) Some of us have better things to do with our time than flame people!