[Design of JBossCache] - Region management issues
by bstansberry@jboss.com
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066421#4066421
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066421
18 years, 5 months
[Design of JBossCache] - Re: New Locking Strategy Proposal for JBoss Cache
by FredrikJ
Allthough I'm not familiar enough with the code to understand every implication of the proposed implementation, I think that the idea is sound.
I encountered blocking reads in our application which need to be addressed. In the end I constructed a local cache in front of the distributed cache. The local cache is updated by the distributed in a fashion where we never block readers. (Optimistically locking was not a perfect fit here, I might revise that in the future if I get the time).
The blocking encountered was not only due to write locked nodes but also synchronization blocks. However, the local cache solved the issues and I now get very performant concurrent reading from the cache layers.
If I haven't gotten this all backwards this is a bit similar to what you propose. And the implications by this is that you would infact be solving a real problem that at least we had to deal with. I think that given the application areas for a cache, fast, non-blocking read access is definitely crucial. And I would love to see it implemented in the core cache instead of a tacked on solution like mine. =)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066397#4066397
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066397
18 years, 5 months