[
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"
**
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