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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904471#3904471
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3904471
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
