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.
I like the overall idea of using regexps to define regions - even aside from the use case you mention, I can see how this is a useful thing, especially once we move to regions being more flexible/configurable.