[ https://issues.jboss.org/browse/ISPN-1132?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1132: ------------------------------------- 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 attribute that controls lock reordering is *reorderLockAcquisition*: {code:xml} <locking lockAtPrepareTime="true" reorderLockAcquisition="true" /> {code} Having *lockAtPrepareTime* disabled and *reorderLockAcquisition* would make the system output 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:java} is replaced with {code:java} for (WriteCommand wc : reorder(command.getModifications())) { acquireLock(wc); } {code:java} * {{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 message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1132?page=com.atlassian.jira.plugin.... ] 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 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1132?page=com.atlassian.jira.plugin.... ] Manik Surtani reassigned ISPN-1132: ----------------------------------- Assignee: Mircea Markus (was: Manik Surtani) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1132?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1132: -------------------------------- Summary: Reorder lock acquisition to avoid deadlocks (was: Locking optimization: reorder lock acquisition to avoid deadlocks ) Labels: locking optimization transaction (was: optimization transaction) Component/s: Locking and Concurrency -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1132?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1132: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/632 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1132?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1132: -------------------------------- Fix Version/s: 5.1.0.BETA5 Git Pull Request: https://github.com/infinispan/infinispan/pull/632 (was: https://github.com/infinispan/infinispan/pull/632) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira