[JBoss JIRA] Closed: (JBCACHE-658) Fast locking for mostly-read PojoCache
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-658?page=all ]
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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[JBoss JIRA] Reopened: (JBCACHE-658) Fast locking for mostly-read PojoCache
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-658?page=all ]
Manik Surtani reopened JBCACHE-658:
-----------------------------------
Assignee: Manik Surtani (was: Jason T. Greene)
> 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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[JBoss JIRA] Created: (JBCACHE-754) RPC return values to use a marshaller as well
by Manik Surtani (JIRA)
RPC return values to use a marshaller as well
---------------------------------------------
Key: JBCACHE-754
URL: http://jira.jboss.com/jira/browse/JBCACHE-754
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0, 2.0.0
Reporter: Manik Surtani
Assigned To: Manik Surtani
Fix For: 2.1.0
Currently, all RPC calls go through the VersionAwareMarshaller which is responsible for efficiently marshalling JBC internal objects as well as user objects using JBoss Serialization.
Return values and exceptions, on the other hand, are marshalled/unmarshalled using JGroups' Util.{to|from}ByteBuffer() which uses standard object serialization.
The problems here are twofold:
1) Relatively inefficient (in speed as well as byte array size) marshalling/unmarshalling for return values
2) Potential class loader problems
Most RPC calls in JBoss Cache do not have return values so this is not a problem that comes up often, but certain features (clustered cache loader, data gravitation in buddy replication) rely on return values.
The solution to this problem is to be able to register a marshaller with the JGroups RPCDispatcher for return values (and exceptions) as well as for the RPC calls themselves.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[JBoss JIRA] Created: (JBCACHE-788) Optimistic locking should not REQUIRE transactions!
by Manik Surtani (JIRA)
Optimistic locking should not REQUIRE transactions!
---------------------------------------------------
Key: JBCACHE-788
URL: http://jira.jboss.com/jira/browse/JBCACHE-788
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0, 1.3.0, 2.0.0
Reporter: Manik Surtani
Assigned To: Manik Surtani
Fix For: 2.1.0
Makes things simpler.
TXs are only used so transaction workspaces can be stored in a transaction entry. This workspace can just as easily be stored in ThreadLocal for non-tx calls (that just have the lifespan of a single invocation).
This will:
1) Make things a LOT quicker since we don't need 2PC for all calls.
2) Make the TxInterceptor a lot simpler
3) Allow the use of Opt Locking without a TM
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months