[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-1132) Locking optimization: reorder lock acquisition to avoid deadlocks

[Mircea Markus (JIRA)]

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

Mircea Markus edited comment on ISPN-1132 at 5/23/11 5:55 PM:
--------------------------------------------------------------

Suggested design.
This feature is only available if *lockAtPrepareTime*, as defined within ISPN-1131, is enabled.
It should be possible to control weather lock-reordering is enabled or not: e.g. there might be application where locks are being acquired in a ordered sequence already, so this optimization would not bring any benefit. 
The element that controls lock reordering is *reorderLockAcquisition*: 
{code:xml}
      <locking lockAtPrepareTime="true">
         <reorderLockAcquisition enabled="true" keyComparator="extends.java.util.Comaparator"/>
      </locking>
{code}
*keyComparator* is optional. It is an {{java.util.Comaparator<K>}} implementation, with K from {{Cache<K,V>}}. If not specified defaults to a implementation that:
* for each key calculates the CH value
* compares the CH values of two keys in order to determine the order.
 
Having *lockAtPrepareTime* disabled and *reorderLockAcquisition* enabled makes the system log a warning stating that lock reordering is not active.

In order to support this feature {{TxInterceptor.visitPrepareCommand}} is modified as follows:
* it would first invoke {{invokeNextInterceptor(ctx, command)}} and only then 
{code:java}
      if (!ctx.isOriginLocal()) {
         // replay modifications
         for (VisitableCommand modification : command.getModifications()) {
            VisitableCommand toReplay = getCommandToReplay(modification);
            if (toReplay != null) {
               invokeNextInterceptor(ctx, toReplay);
            }
         }
      }
{code}
* this is needed in order to have {{LockInterceptor.visitPrepareCommand}} acquire locks at once for all keys involved in the transaction

Also {{PrepareTimeLockingInterceptor.visitPrepareCommand}} is enhanced as follows:
* {code:java} for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } {code} 
    is replaced with
{code:java} for (WriteCommand wc : reorder(command.getModifications())) { acquireLock(wc); } {code} 
* {{reorder(WriteCommand[] commandsToReorder)}} works as follows:
** if *reorderLockAcquisition* is disabled returns {{commandsToReorder}}
** if {{commandsToReorder}} contrains a {{ClearCommand}} it returns {{commandsToReorder}} (unmodified)
** breaks {{PutMapCommand}} in individual {{PutKeyValue}} commands
** after the step above we have a sequence of {{DataCommands}} - based on the original {{commandsToReorder}} sequence, with {{PutMapCommand}} "expanded"
** this sequence is the coalesced (a la ISPN-328), resulting in another sequence of {{DataCommands}}
** A List<K> is then determined from last {{DataCommands}} sequence by using {{DataCommands.getKey()}}. (K from Cache<K,V>) 
** This list of keys is then ordered using the configured *keyComparator* 
** locks are being acquired in the sequence resulted at the previous step
 



      was (Author: mircea.markus):
    Suggested design.
This feature is only available if *lockAtPrepareTime*, as defined within ISPN-1131, is enabled.
It should be possible to control weather lock-reordering is enabled or not: e.g. there might be application where locks are being acquired in a ordered sequence already, so this optimization would not bring any benefit. 
The element that controls lock reordering is *reorderLockAcquisition*: 
{code:xml}
      <locking lockAtPrepareTime="true">
         <reorderLockAcquisition enabled="true" keyComparator="extends.java.util.Comaparator"/>
      </locking>
{code}
*keyComparator* is optional. It is an {{java.util.Comaparator<K>}} implementation, with K from {{Cache<K,V>}}. If not specified defaults to a implementation that:
* for each key calculates the CH value
* compares the CH values of two keys in order to determine the order.
 
Having *lockAtPrepareTime* disabled and *reorderLockAcquisition* enabled makes the system log a warning stating that lock reordering is not active.

In order to support this feature {{TxInterceptor.visitPrepareCommand}}is modified as follows:
* it would first invoke {{invokeNextInterceptor(ctx, command)}} and only then 
{code:java}
      if (!ctx.isOriginLocal()) {
         // replay modifications
         for (VisitableCommand modification : command.getModifications()) {
            VisitableCommand toReplay = getCommandToReplay(modification);
            if (toReplay != null) {
               invokeNextInterceptor(ctx, toReplay);
            }
         }
      }
{code}
* this is needed in order to have {{LockInterceptor.visitPrepareCommand}} acquire locks at once for all keys involved in the transaction

Also {{PrepareTimeLockingInterceptor.visitPrepareCommand}} is enhanced as follows:
* {code:java} for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } {code} 
    is replaced with
{code:java} for (WriteCommand wc : reorder(command.getModifications())) { acquireLock(wc); } {code} 
* {{reorder(WriteCommand[] commandsToReorder)}} works as follows:
** if *reorderLockAcquisition* is disabled returns {{commandsToReorder}}
** if {{commandsToReorder}} contrains a {{ClearCommand}} it returns {{commandsToReorder}} (unmodified)
** breaks {{PutMapCommand}} in individual {{PutKeyValue}} commands
** after the step above we have a sequence of {{DataCommands}} - based on the original {{commandsToReorder}} sequence, with {{PutMapCommand}} "expanded"
** this sequence is the coalesced (a la ISPN-328), resulting in another sequence of {{DataCommands}}
** A List<K> is then determined from last {{DataCommands}} sequence by using {{DataCommands.getKey()}}. (K from Cache<K,V>) 
** This list of keys is then ordered using the configured *keyComparator* 
** locks are being acquired in the sequence resulted at the previous step
 


  
> Locking optimization: reorder lock acquisition to avoid deadlocks  
> -------------------------------------------------------------------
>
>                 Key: ISPN-1132
>                 URL: https://issues.jboss.org/browse/ISPN-1132
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Transactions
>            Reporter: Mircea Markus
>            Assignee: Manik Surtani
>              Labels: optimization, transaction
>             Fix For: 5.1.0.Final
>
>
> Detailed here, as the 3rd 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