[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-1137) Locking optimization: only lock main data owner (dist only)

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1137 at 6/17/11 5:27 AM: -------------------------------------------------------------- Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this depends on implementing ISPN-1131, which is experimental as well, *lockingSingleNode* is only available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode the configuration is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the given key{s} have as main data owner the node where the prepare executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Interference with non transactional operations is also a concern, as in its current form, a non transactional operation would acquire and apply a change on non-owners disregarding the lock on the main data owner. Manik suggested an approach similar to then one used in JSR-107: 1) If a cache is non-transactional, transactional threads accessing the cache throw an exception. 2) If a cache is transactional, threads must have an ongoing transaction. If not, an exception is thrown, unless: 3) Auto-commit is configured to be true. In this case, if a non-transactional thread accesses the cache, a tx is started, work done, and the tx auto-committed. Handling failure situations: if a node on which a remote lock is acquired fails between prepare and before commit, the prepare is re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). was (Author: mircea.markus): Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this depends on implementing ISPN-1131, which is experimental as well, *lockingSingleNode* is only available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode the configuration is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the given key{s} have as main data owner the node where the prepare executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Interference with non transactional operations is also a concern, as in its current form, a non transactional operation would acquire and apply a change on non-owners disregarding the lock on the main data owner. To avoid this situation, non-transactional operations will be transparently wrapped within a transaction. This approach two significant side effects: * the regular operations would be more costly because they now happen in 2 phases, ie 2 RPCs * solves problem #2, as described in the [PossibleLockingImprovements|http://community.jboss.org/wiki/PossibleLocki...] document Handling failure situations: if a node on which a remote lock is acquired fails between prepare and before commit, the prepare is re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira