February 2017 - infinispan-issues

[JBoss JIRA] (ISPN-7526) Write skew check throws even if the previous value was not read

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7526?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-7526: ----------------------------------- [~dan.berindei] I think that write skew check should check that *preconditions* of the transaction did not changed, rather than any concurrent update to the value. If the transactions were serialized, the update could happen just before the transaction starts/read is executed. However, the situation is even worse when the key is non-local: this test fails: {code:java} final Object key = new MagicKey("ignore-return-value", cache(0)); final AdvancedCache<Object, Object> c = advancedCache(1); final TransactionManager tm = tm(1); cache(0).put(key, "init"); tm.begin(); c.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).put(key, "v1"); c.replace(key, "v1", "v2"); tm.commit(); // throws WSCE {code} because the replace command is not forced to retrieve the remote entry (the value is already cached in context). Therefore, the seen version for WSC is a non-existent version, which does not match the actual version. There are two ways to fix this: a) don't do the check as we haven't seen any version b) force remote read with {{IGNORE_RETURN_VALUES}} if the entry is not yet in the context. > Write skew check throws even if the previous value was not read > --------------------------------------------------------------- > > Key: ISPN-7526 > URL: https://issues.jboss.org/browse/ISPN-7526 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 9.0.0.CR2, 8.2.6.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > > When the entry was overwritten without reading previous value and then we read it (this read is handled from the current context), write skew check is still applied and can fail, despite that it's unnecessary. > {code:java} > cache.put("k", "init"); > tm.begin(); > cache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).put("k", "v1"); > assertEquals("v1", cache.put("k", "v2")); > Transaction tx = tm.suspend(); > assertEquals("init", cache.put("k", "other")); > tm.resume(tx); > tm.commit(); // fails with WriteSkewCheckException > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7528) Store CacheTransaction.keyRead(...) in RepeatableReadEntry

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7528?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-7528: ----------------------------------- [~dan.berindei] When OptimisticLockingInterceptor is invoked, the entry is not wrapped in the context yet, so we have to mark it later. But yes, I had {{ReadCommittedEntry.setFlag(Flags.READ)}} in mind. > Store CacheTransaction.keyRead(...) in RepeatableReadEntry > ---------------------------------------------------------- > > Key: ISPN-7528 > URL: https://issues.jboss.org/browse/ISPN-7528 > Project: Infinispan > Issue Type: Enhancement > Reporter: Radim Vansa > Assignee: Radim Vansa > > Rather than keeping another collection of keys ({{LocalTransaction.readKeys}}), we could store the information if the key was read in flag for RepeatableReadEntry. > That would require marking the read keys in EntryFactory, though, rather than in OptimisticLockingInterceptor. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7530) InfinispanStoreRocksDBIT leaves files in the current directory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7530?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7530: ------------------------------- Status: Open (was: New) > InfinispanStoreRocksDBIT leaves files in the current directory > -------------------------------------------------------------- > > Key: ISPN-7530 > URL: https://issues.jboss.org/browse/ISPN-7530 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.CR3 > > > {{InfinispanStoreRocksDBIT}} sets the store's main {{location}}, but not {{expiredLocation}}, so the expired RocksDB directory is created in the current directory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7530) InfinispanStoreRocksDBIT leaves files in the current directory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7530?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7530: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4902 > InfinispanStoreRocksDBIT leaves files in the current directory > -------------------------------------------------------------- > > Key: ISPN-7530 > URL: https://issues.jboss.org/browse/ISPN-7530 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.CR3 > > > {{InfinispanStoreRocksDBIT}} sets the store's main {{location}}, but not {{expiredLocation}}, so the expired RocksDB directory is created in the current directory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7530) InfinispanStoreRocksDBIT leaves files in the current directory

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7530: ---------------------------------- Summary: InfinispanStoreRocksDBIT leaves files in the current directory Key: ISPN-7530 URL: https://issues.jboss.org/browse/ISPN-7530 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 9.0.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 9.0.0.CR3 {{InfinispanStoreRocksDBIT}} sets the store's main {{location}}, but not {{expiredLocation}}, so the expired RocksDB directory is created in the current directory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7529) Upgrade Caffeine to 2.4

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7529?page=com.atlassian.jira.plugin.... ] Work on ISPN-7529 started by William Burns. ------------------------------------------- > Upgrade Caffeine to 2.4 > ----------------------- > > Key: ISPN-7529 > URL: https://issues.jboss.org/browse/ISPN-7529 > Project: Infinispan > Issue Type: Task > Components: Eviction > Reporter: William Burns > Assignee: William Burns > > Caffeine has fixed a few more bugs. We should update. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7529) Upgrade Caffeine to 2.4

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7529?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7529: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/4901 > Upgrade Caffeine to 2.4 > ----------------------- > > Key: ISPN-7529 > URL: https://issues.jboss.org/browse/ISPN-7529 > Project: Infinispan > Issue Type: Task > Components: Eviction > Reporter: William Burns > Assignee: William Burns > > Caffeine has fixed a few more bugs. We should update. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7529) Upgrade Caffeine to 2.4

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7529?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7529: -------------------------------- Status: Open (was: New) > Upgrade Caffeine to 2.4 > ----------------------- > > Key: ISPN-7529 > URL: https://issues.jboss.org/browse/ISPN-7529 > Project: Infinispan > Issue Type: Task > Components: Eviction > Reporter: William Burns > Assignee: William Burns > > Caffeine has fixed a few more bugs. We should update. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7528) Store CacheTransaction.keyRead(...) in RepeatableReadEntry

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7528?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7528: ------------------------------------ Couldn't {{OptimisticLockingInterceptor}} use {{ReadCommittedEntry.setFlag(Flags.READ)}}? > Store CacheTransaction.keyRead(...) in RepeatableReadEntry > ---------------------------------------------------------- > > Key: ISPN-7528 > URL: https://issues.jboss.org/browse/ISPN-7528 > Project: Infinispan > Issue Type: Enhancement > Reporter: Radim Vansa > Assignee: Radim Vansa > > Rather than keeping another collection of keys ({{LocalTransaction.readKeys}}), we could store the information if the key was read in flag for RepeatableReadEntry. > That would require marking the read keys in EntryFactory, though, rather than in OptimisticLockingInterceptor. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7527) Local write skew check cannot work with persistence

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7527?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7527: ------------------------------------ Looking at {{LockingConfigurationBuilder.validate()}} we already force the user to enable versioning even for local caches, so I think it should be easy to just use the versions regardless of cache mode. > Local write skew check cannot work with persistence > --------------------------------------------------- > > Key: ISPN-7527 > URL: https://issues.jboss.org/browse/ISPN-7527 > Project: Infinispan > Issue Type: Bug > Reporter: Radim Vansa > > The local write skew check is not based on comparing versions but object refences in container. If the entry is evicted/passivated during a transaction, the reference is removed from container and write skew check throws exception. Loading from persistence layer is insufficient as we load a copy of the instance. > Good thing is this may cause false negatives (spurious failures), but does not affect consistency. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2017