|
If you were logged in you would be able to see more operations.
|
|
|
|
Apparently we have not been using tree cache in the most proper manner in regards to Fqn construction. The way in which we construct Fqns actually leads to a very flat tree structure. For example consider a region for "org.hibernate.test.hql.Animal"; this actually leads to a tree node structured like:
/org/hibernate/test/hql/Animal
/id1
/id2
/...
Notice that the Hibernate region-name leads to a flat node which is a direct child of the root node...
The issue is twofold:
1) This may be one of the causes of the high level of contention in the older pessimistic TreeCache model
2) This is currently causing problems with the optimistic locking stuff because the "parent" node is version-incremented whenever its children is mutated (child added/removed)
|
|
Description
|
Apparently we have not been using tree cache in the most proper manner in regards to Fqn construction. The way in which we construct Fqns actually leads to a very flat tree structure. For example consider a region for "org.hibernate.test.hql.Animal"; this actually leads to a tree node structured like:
/org/hibernate/test/hql/Animal
/id1
/id2
/...
Notice that the Hibernate region-name leads to a flat node which is a direct child of the root node...
The issue is twofold:
1) This may be one of the causes of the high level of contention in the older pessimistic TreeCache model
2) This is currently causing problems with the optimistic locking stuff because the "parent" node is version-incremented whenever its children is mutated (child added/removed) |
Show » |
|
Improvement
Closed
Major
TreeCache based providers and Fqn
Fqn regionFqn = Fqn.fromString( regionName.replace( '.', '/' ) );
cache.put( new Fqn( regionFqn, key ), ITEM, value, option );