[JBoss JIRA] (ISPN-3542) Read Only transaction optimization doesn't work properly for RepeatableRead
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3542?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3542:
--------------------------------
Fix Version/s: 6.0.0.Beta2
> Read Only transaction optimization doesn't work properly for RepeatableRead
> ---------------------------------------------------------------------------
>
> Key: ISPN-3542
> URL: https://issues.jboss.org/browse/ISPN-3542
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Beta1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Beta2
>
> Attachments: ISPN-3542-patch
>
>
> There is a readOnly optimization that Infinispan does to make sure we don't do a 2PC when there is no data to update. However the code for this does
> {code}
> public boolean isReadOnly() {
> return (modifications == null || modifications.isEmpty()) && (lookedUpEntries == null || lookedUpEntries.isEmpty());
> }
> {code}
> For repeatable read we always add a value to lookedUpEntries so this optimization never works that isolation level.
> Looking closer it seems we do a 1PC when it is readOnly to clean up values, so there shouldn't be a need to care about lookedUpEntries (my guess is this was done as a way to test for locks).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3542) Read Only transaction optimization doesn't work properly for RepeatableRead
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3542?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3542:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2096
> Read Only transaction optimization doesn't work properly for RepeatableRead
> ---------------------------------------------------------------------------
>
> Key: ISPN-3542
> URL: https://issues.jboss.org/browse/ISPN-3542
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Beta1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Beta2
>
> Attachments: ISPN-3542-patch
>
>
> There is a readOnly optimization that Infinispan does to make sure we don't do a 2PC when there is no data to update. However the code for this does
> {code}
> public boolean isReadOnly() {
> return (modifications == null || modifications.isEmpty()) && (lookedUpEntries == null || lookedUpEntries.isEmpty());
> }
> {code}
> For repeatable read we always add a value to lookedUpEntries so this optimization never works that isolation level.
> Looking closer it seems we do a 1PC when it is readOnly to clean up values, so there shouldn't be a need to care about lookedUpEntries (my guess is this was done as a way to test for locks).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-3266:
-----------------------------------
Assignee: William Burns (was: Pedro Ruivo)
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.CR1
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3266 started by William Burns.
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.CR1
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3266:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.CR1)
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Beta2
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3266:
-------------------------------------
Actually that won't work - it only is part of the solution as I was fearing :)
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.CR1
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3542) Read Only transaction optimization doesn't work properly for RepeatableRead
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3542?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3542 started by William Burns.
> Read Only transaction optimization doesn't work properly for RepeatableRead
> ---------------------------------------------------------------------------
>
> Key: ISPN-3542
> URL: https://issues.jboss.org/browse/ISPN-3542
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Beta1
> Reporter: William Burns
> Assignee: William Burns
> Attachments: ISPN-3542-patch
>
>
> There is a readOnly optimization that Infinispan does to make sure we don't do a 2PC when there is no data to update. However the code for this does
> {code}
> public boolean isReadOnly() {
> return (modifications == null || modifications.isEmpty()) && (lookedUpEntries == null || lookedUpEntries.isEmpty());
> }
> {code}
> For repeatable read we always add a value to lookedUpEntries so this optimization never works that isolation level.
> Looking closer it seems we do a 1PC when it is readOnly to clean up values, so there shouldn't be a need to care about lookedUpEntries (my guess is this was done as a way to test for locks).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3266:
-------------------------------------
Also you can disregard my test case, it was flawed. I have a couple tests I will be adding to ISPN-3542 that should be fixed by this though.
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.CR1
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3266:
-------------------------------------
I am not for sure but it looks like all that is required here is:
{code}
diff --git a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticL
index ba9714a..39ff611 100644
--- a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingI
+++ b/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingI
@@ -63,6 +63,9 @@ public final Object visitGetKeyValueCommand(InvocationContext
try {
if (command.hasFlag(Flag.FORCE_WRITE_LOCK)) {
boolean skipLocking = hasSkipLocking(command);
+ if (!skipLocking) {
+ acquireRemoteIfNeeded(ctx, command, cdl.localNodeIsPrimaryOwner(
+ }
long lockTimeout = getLockAcquisitionTimeout(command, skipLocking);
lockKeyAndCheckOwnership(ctx, command.getKey(), lockTimeout, skipLo
}
{code}
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.CR1
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
William Burns edited comment on ISPN-3266 at 9/23/13 2:10 PM:
--------------------------------------------------------------
I am not for sure but it looks like all that is required here is:
{code}
diff --git a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingInterceptor.java b/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingInterceptor.java
index ba9714a..39ff611 100644
--- a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingInterceptor.java
+++ b/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingInterceptor.java
@@ -63,6 +63,9 @@ public final Object visitGetKeyValueCommand(InvocationContext ctx, GetKeyValueCo
try {
if (command.hasFlag(Flag.FORCE_WRITE_LOCK)) {
boolean skipLocking = hasSkipLocking(command);
+ if (!skipLocking) {
+ acquireRemoteIfNeeded(ctx, command, cdl.localNodeIsPrimaryOwner(command.getKey()));
+ }
long lockTimeout = getLockAcquisitionTimeout(command, skipLocking);
lockKeyAndCheckOwnership(ctx, command.getKey(), lockTimeout, skipLocking);
}
{code}
was (Author: william.burns):
I am not for sure but it looks like all that is required here is:
{code}
diff --git a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticL
index ba9714a..39ff611 100644
--- a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingI
+++ b/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingI
@@ -63,6 +63,9 @@ public final Object visitGetKeyValueCommand(InvocationContext
try {
if (command.hasFlag(Flag.FORCE_WRITE_LOCK)) {
boolean skipLocking = hasSkipLocking(command);
+ if (!skipLocking) {
+ acquireRemoteIfNeeded(ctx, command, cdl.localNodeIsPrimaryOwner(
+ }
long lockTimeout = getLockAcquisitionTimeout(command, skipLocking);
lockKeyAndCheckOwnership(ctx, command.getKey(), lockTimeout, skipLo
}
{code}
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.CR1
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months