Region management issues
Some unit test fixing Vladimir did has uncovered a change between 1.x and 2.0 in terms of region management. In 1.x there's no need to register a classloader with a region before you can activate it. I.e. the activation/inactivation feature did not require classloader registration. So, you could use the feature even if you didn't need to unmarshall using a special classloader.
Let's discuss whether we care about that use case or not on a separate thread. :-) I just bring it up as an intro to a discussion about how region management works in 2.0:
The requirement to register a classloader was introduced due to this in RegionManager.getReqion(Fqn, Region.Type, boolean) :
Region r = regionsRegistry.get(fqnToUse);
// this is a very poor way of telling whether a region is a marshalling one or an eviction one. :-(
// mandates that class loaders be registered for marshalling regions.
if (type == Region.Type.ANY
|| (type == Region.Type.MARSHALLING && r.getClassLoader() != null)
|| (type == Region.Type.EVICTION && r.getEvictionPolicyConfig() != null))
{
return r;
}This testing is designed to make it easy discriminate between regions used for eviction and those used for marshalling.
As an alternative, how about getting rid of Region.Type and instead implement nesting of regions? Pseudo-code:
public Region(Fqn fqn, Region parent)
{
this.fqn = fqn;
this.parent = parent;
}
public Region getParent()
{
return this.parent;
}
public ClassLoader getClassLoader()
{
ClassLoader result = this.classLoader;
if (result == null && this.parent != null)
result = parent.getClassLoader();
return result;
}
// Same thing for getEvictionRegionConfig, etc.
We could possibly get rid of Region.Type.
One problem I see with this approach is CacheMarshaller200.extractRegionFqn() could end up finding a region below the one where the classloader is registered, with the result that the marshalling fqn included with the region is bigger than it needs to be. E.g.
Region high = cache.getRegion(Fqn.fromString("/a"), true);
high.registerContextClassLoader(someCL);
...
Region deep = cache.getRegion(Fqn.fromString("/a/b/c/d/e/f"), true);
deep.setEvictionPolicyConfig(someConfig);
(I can see any easy solution to that though, if we keep Region.Type as a hint to the getRegion() method).)
A benefit of nesting is the eviction code should be able to find the EvictionPolicy much faster when a node that's experienced an event is far below the eviction region. RegionManager.getReqion(Fqn, Region.Type, boolean) current looks for the fqn in the region map, and then checks if it's the correct type. If not, it moves up to the fqn parent and tries that. Multiple map lookups.
