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

[Mircea Markus (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604065#comment-12604065 ] 

Mircea Markus edited comment on ISPN-1137 at 5/24/11 5:10 PM:
--------------------------------------------------------------

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/PossibleLockingImprovements] 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). 



      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}}.

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). 


  
> Locking optimization: for dist lock only main data owner 
> ---------------------------------------------------------
>
>                 Key: ISPN-1137
>                 URL: https://issues.jboss.org/browse/ISPN-1137
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 4.2.1.FINAL
>            Reporter: Mircea Markus
>            Assignee: Manik Surtani
>              Labels: optimization
>
> Detailed here, as the 4th improvement: http://community.jboss.org/wiki/PossibleLockingImprovements
> As without ISPN-1131 locks are being acquired as the transaction progresses this optimization makes more sense after having ISPN-1131 in place.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira