This post is related to Brian's post re: "Optimistic locking doesn't scale
well with large 'flat' cache":
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112462
As Brian mentioned, the customer has some eviction issues with those structural/bucket
style nodes created.
These buckets allow to spread the nodes through different levels, making the child maps
smaller. However, this buckets/structural nodes make the evictions run earlier than they
would expect.
This is what I had in mind to get around it:
1.- We could enable specification of non static eviction regions, for example via regular
expressions.
2.- Each region allows us to define a specific policy for it, so we could create one that
processes any region that matches this regular expression. Regions are created on startup,
but could be created them on the fly, as we find Fqns that match the regular expression.
3.- Creating a regular expression for a region like x/y/z where x,y, and z are numbers
should be easy (customer were using hascodes for the bucket fqn names). Java
variable/class/package names cannot be just numbers so you would avoid misleading a bucket
region from a non bucket region. This would be handy in the 2nd level cache spectrum.
Customer built caches could define their own buckets.
4.- The Eviction algorithm in the process(Region) call, could take the regular
expression, find any regions that match them and then call this.processQueues(region) for
each of these regions, and finally empty the queues and prune.
5.- Finding an quick way to match Regions based on a regular expression would require
further thought (meaning, I need to look into it :) ).
This might give us a lot of flexibility in the long term on how evictions regions are
defined.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060911#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...