[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 4:46 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}}.

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 will be implemented after ISPN-1131, which is experimental as well, *lockingSingleNode* would only be 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 it 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 key{s} have as main data owner the node where the code 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 after prepare and before commit, the prepare will be 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