June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2657) Support for LevelDB CacheStore

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2657?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2657: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 974403|https://bugzilla.redhat.com/show_bug.cgi?id=974403] > Support for LevelDB CacheStore > ------------------------------ > > Key: ISPN-2657 > URL: https://issues.jboss.org/browse/ISPN-2657 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Ray Tsang > Assignee: Ray Tsang > Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final > > > Support for LevelDB, a fast key-value persistence storage. > There is a pure java implementation and a jni by fuse -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3164) Replacing entry via Memcached does not increment version of original HotRod entry

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3164?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-3164. ------------------------------------ Fix Version/s: (was: 5.3.0.Final) Resolution: Duplicate Issue > Replacing entry via Memcached does not increment version of original HotRod entry > --------------------------------------------------------------------------------- > > Key: ISPN-3164 > URL: https://issues.jboss.org/browse/ISPN-3164 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > > When an entry is stored via HotRod and later replaced by Memcached (or Embedded, it does not matter), the version of the entry does not change. This makes operations like replaceWithVersion of HotRod client unreliable in compatibility mode. > {code:java} > public void testHotRodPutMemcachedReplaceHotRodGetVersionedTest() throws Exception { > final String key1 = "6"; > // 1. Put with Hot Rod > RemoteCache<String, Object> remote = cacheFactory.getHotRodCache(); > assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key1, "v1")); > VersionedValue oldValue = remote.getVersioned(key1); > // 2. Replace with Memcached > Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v2"); > assertTrue(f.get(60, TimeUnit.SECONDS)); > // 3. Get with HotRod > assertEquals("v2", remote.getVersioned(key1).getValue()); > assertTrue("The entry version should have changed", oldValue.getVersion() != remote.getVersioned(key1).getVersion()); > //^^^ fails here > } > {code} -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3236) Repeatable Read: Transactions are not isolated when read non-existing keys

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3236?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3236: ------------------------------ Description: Repeatable read transaction is not isolated when they read a non-existing key. tm.begin() cache.get(k) //returns null //in the meanwhile a transaction writes on k and commits cache.get(k) //return the new value. IMO, this is not valid for REPEATABLE_READ isolation level! //TODO add a test case for all the write operations (except put map because it does not read the old value) tm.begin() cache.get(k) //returns null (op#1) //in the meanwhile a transaction writes on k and commits write operation performed: * put: must return the same value as op#1 * conditional put //if op#1 returns null the operation should be always successful (i.e. the key is updated, return true). Otherwise, the key remains unchanged (return false) * replace: must return the same value as op#1 * conditional replace: replace should be successful if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false). * remote: must return the same value as op#1 * conditional remove: the key should be removed if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false) //TODO2: check if after a remove, the following get return null and the description above is still valid. was: Repeatable read transaction is not isolated when they read a non-existing key. tm.begin() cache.get(k) //returns null //in the meanwhile a transaction writes on k and commits cache.get(k) //return the new value. IMO, this is not valid for REPEATABLE_READ isolation level! //TODO add a test case for all the write operations (except put map because it does not read the old value) * put() //assert the return value * conditional put //if cache.get(k) returns null the putIfAbsent should never fail. Vice-version if cache.get(k) returns non-null * conditional replace //replace should never fail if used as old value the cache.get(k). And vice-versa * conditional remove //remove should never fail if used as old value the cache.get(k). And vice-versa > Repeatable Read: Transactions are not isolated when read non-existing keys > -------------------------------------------------------------------------- > > Key: ISPN-3236 > URL: https://issues.jboss.org/browse/ISPN-3236 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: isolation > Fix For: 5.3.0.Final > > > Repeatable read transaction is not isolated when they read a non-existing key. > tm.begin() > cache.get(k) //returns null > //in the meanwhile a transaction writes on k and commits > cache.get(k) //return the new value. IMO, this is not valid for > REPEATABLE_READ isolation level! > //TODO add a test case for all the write operations (except put map because it does not read the old value) > tm.begin() > cache.get(k) //returns null (op#1) > //in the meanwhile a transaction writes on k and commits > write operation performed: > * put: must return the same value as op#1 > * conditional put //if op#1 returns null the operation should be always successful (i.e. the key is updated, return true). Otherwise, the key remains unchanged (return false) > * replace: must return the same value as op#1 > * conditional replace: replace should be successful if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false). > * remote: must return the same value as op#1 > * conditional remove: the key should be removed if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false) > //TODO2: check if after a remove, the following get return null and the description above is still valid. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3237) Check if the lock acquisition can be removed for remote fetch entries in optimistic caches

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3237?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3237: ------------------------------ Summary: Check if the lock acquisition can be removed for remote fetch entries in optimistic caches (was: Check if the lockAndWrap() can be removed for remote fetch entries in optimistic caches) > Check if the lock acquisition can be removed for remote fetch entries in optimistic caches > ------------------------------------------------------------------------------------------ > > Key: ISPN-3237 > URL: https://issues.jboss.org/browse/ISPN-3237 > Project: Infinispan > Issue Type: Enhancement > Components: Locking and Concurrency, Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: locking > Fix For: 5.3.0.Final > > > When a remote get is performed, it tries to lock the key in the originator. However: > * the originator is not an owner, so nothing will be locked > * in optimistic caches, the lock should be only acquired in the prepare phase -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3237) Check if the lockAndWrap() can be removed for remote fetch entries in optimistic caches

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3237: --------------------------------- Summary: Check if the lockAndWrap() can be removed for remote fetch entries in optimistic caches Key: ISPN-3237 URL: https://issues.jboss.org/browse/ISPN-3237 Project: Infinispan Issue Type: Enhancement Components: Locking and Concurrency, Transactions Affects Versions: 5.3.0.CR1 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Priority: Minor Fix For: 5.3.0.Final When a remote get is performed, it tries to lock the key in the originator. However: * the originator is not an owner, so nothing will be locked * in optimistic caches, the lock should be only acquired in the prepare phase -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3235) Repeatable Read: should skip remote get if the key was previously read

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3235?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3235: ------------------------------ Summary: Repeatable Read: should skip remote get if the key was previously read (was: Repeatable Read: skip remote get if the key was previously read) > Repeatable Read: should skip remote get if the key was previously read > ---------------------------------------------------------------------- > > Key: ISPN-3235 > URL: https://issues.jboss.org/browse/ISPN-3235 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 5.3.0.Final > > > When Repeatable Read, if the key was previously read or write, skip the remote fetch since the value return is discarded. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3235) Repeatable Read: should skip remote get if the key was previously read

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3235?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3235: ------------------------------ Component/s: Transactions > Repeatable Read: should skip remote get if the key was previously read > ---------------------------------------------------------------------- > > Key: ISPN-3235 > URL: https://issues.jboss.org/browse/ISPN-3235 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 5.3.0.Final > > > When Repeatable Read, if the key was previously read or write, skip the remote fetch since the value return is discarded. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3235) Repeatable Read: should skip remote get if the key was previously read

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3235?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3235: ------------------------------ Labels: improvement transaction (was: ) > Repeatable Read: should skip remote get if the key was previously read > ---------------------------------------------------------------------- > > Key: ISPN-3235 > URL: https://issues.jboss.org/browse/ISPN-3235 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: improvement, transaction > Fix For: 5.3.0.Final > > > When Repeatable Read, if the key was previously read or write, skip the remote fetch since the value return is discarded. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3236) Repeatable Read: Transactions are not isolated when read non-existing keys

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3236?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3236: ------------------------------ Labels: isolation (was: ) > Repeatable Read: Transactions are not isolated when read non-existing keys > -------------------------------------------------------------------------- > > Key: ISPN-3236 > URL: https://issues.jboss.org/browse/ISPN-3236 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: isolation > Fix For: 5.3.0.Final > > > Repeatable read transaction is not isolated when they read a non-existing key. > tm.begin() > cache.get(k) //returns null > //in the meanwhile a transaction writes on k and commits > cache.get(k) //return the new value. IMO, this is not valid for > REPEATABLE_READ isolation level! > //TODO add a test case for all the write operations (except put map because it does not read the old value) > * put() //assert the return value > * conditional put //if cache.get(k) returns null the putIfAbsent should never fail. Vice-version if cache.get(k) returns non-null > * conditional replace //replace should never fail if used as old value the cache.get(k). And vice-versa > * conditional remove //remove should never fail if used as old value the cache.get(k). And vice-versa -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3236) Repeatable Read: Transactions are not isolated when read non-existing keys

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3236: --------------------------------- Summary: Repeatable Read: Transactions are not isolated when read non-existing keys Key: ISPN-3236 URL: https://issues.jboss.org/browse/ISPN-3236 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.3.0.CR1 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 5.3.0.Final Repeatable read transaction is not isolated when they read a non-existing key. tm.begin() cache.get(k) //returns null //in the meanwhile a transaction writes on k and commits cache.get(k) //return the new value. IMO, this is not valid for REPEATABLE_READ isolation level! //TODO add a test case for all the write operations (except put map because it does not read the old value) * put() //assert the return value * conditional put //if cache.get(k) returns null the putIfAbsent should never fail. Vice-version if cache.get(k) returns non-null * conditional replace //replace should never fail if used as old value the cache.get(k). And vice-versa * conditional remove //remove should never fail if used as old value the cache.get(k). And vice-versa -- 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, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013