]
Manik Surtani closed JBCACHE-658.
---------------------------------
Fix Version/s: (was: 2.1.0.GA)
Resolution: Deferred
Fast locking for mostly-read PojoCache
--------------------------------------
Key: JBCACHE-658
URL:
http://jira.jboss.com/jira/browse/JBCACHE-658
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Legacy POJO Cache
Reporter: Nitzan Niv
Assigned To: Manik Surtani
The locking mechanism locks all the nodes in the path from the tree root to the modified
node. If the cache contains a deep hierarchy of nodes (e.g., PojoCache that contains
complex objects) and the usage of the cache
is mostly-read the locking overhead is unnecessarilly large.
To enable REPEATABLE_READ isolation level with minimal overhead (but with reduced update
parallelism) just the tree root should be locked instead of the nodes-path. To define this
policy as a new isloation level ("single"):
Change in PessimisticLockInterceptor (line 199):
else {
if(isolation_level == IsolationLevel.SINGLE) {//XXX
if (i == 0) {
acquired=child_node.acquire(owner, lock_timeout, lock_type);
}
} else {
if(lock_type == DataNode.LOCK_TYPE_WRITE && i == (treeNodeSize - 1))
{
acquired=child_node.acquire(owner, lock_timeout,
DataNode.LOCK_TYPE_WRITE);
}
else {
acquired=child_node.acquire(owner, lock_timeout,
DataNode.LOCK_TYPE_READ);
}
}//XXX
}
in LockStrategyFactory.java:
if (lockingLevel == IsolationLevel.REPEATABLE_READ || lockingLevel ==
IsolationLevel.SINGLE) //XXX
return new LockStrategyRepeatableRead();
and add the "SINGLE" isolation level to IsolationLevel.java.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: