September 2013 - infinispan-issues

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-470. -------------------------------- Resolution: Migrated to another ITS tracked here: https://issues.jboss.org/browse/HRCPP > Native Hot Rod client for C++ > ----------------------------- > > Key: ISPN-470 > URL: https://issues.jboss.org/browse/ISPN-470 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Beta2, 6.0.0.CR1 > > Attachments: straw.patch > > > C++ client impl for HotRod. Protocol is documented here: > http://community.jboss.org/wiki/HotRodProtocol > Could be based off the Java reference impl client: > https://github.com/infinispan/infinispan/tree/master/client/hotrod-client -- 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

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013