[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)
9 years, 1 month
[JBoss JIRA] (ISPN-7526) Write skew check throws even if the previous value was not read
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7526?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-7526 at 2/24/17 9:44 AM:
-------------------------------------------------------------
I'm not convinced this is a bug. I guess it depends on how we define optimistic transactions, but I'd argue that if a part of the transaction reads a key from the cache, it expects write skew check for that key regardless of where the actual value came from.
was (Author: dan.berindei):
I'm not convinced this is a bug. I guess it depends on how we define optimistic transactions, but I'd argue that if a part of the transaction reads a key from the cache, we should perform write skew check for that key regardless of where the actual value came from.
> 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)
9 years, 1 month
[JBoss JIRA] (ISPN-7526) Write skew check throws even if the previous value was not read
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7526?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-7526:
------------------------------------
I'm not convinced this is a bug. I guess it depends on how we define optimistic transactions, but I'd argue that if a part of the transaction reads a key from the cache, we should perform write skew check for that key regardless of where the actual value came from.
> 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)
9 years, 1 month
[JBoss JIRA] (ISPN-7529) Upgrade Caffeine to 2.5
by William Burns (JIRA)
William Burns created ISPN-7529:
-----------------------------------
Summary: Upgrade Caffeine to 2.5
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)
9 years, 1 month
[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3927:
------------------------------
Description:
Umbrella JIRA for several transaction related improvements:
-1. Async options for commit/rollback- (DONE)
- they don't really make sense as a user you don't get any guarantee on the status of the transaction
- they complicate the code significantly
- I think they should be removed
2. READ_COMMITTED
- it has the same performance as REPEATABLE_READ, but offers less guarantees.
- unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
- I think it should be removed
3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition
- they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
- suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
- build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
4. Remove 1PC option
- I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
[1] http://markmail.org/thread/a7fjko4dyejxqgdy
[2] https://github.com/infinispan/infinispan/pull/2177
[3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
[4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
was:
Umbrella JIRA for several transaction related improvements:
1. Async options for commit/rollback
- they don't really make sense as a user you don't get any guarantee on the status of the transaction
- they complicate the code significantly
- I think they should be removed
2. READ_COMMITTED
- it has the same performance as REPEATABLE_READ, but offers less guarantees.
- unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
- I think it should be removed
3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition
- they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
- suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
- build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
4. Remove 1PC option
- I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
[1] http://markmail.org/thread/a7fjko4dyejxqgdy
[2] https://github.com/infinispan/infinispan/pull/2177
[3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
[4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
> rethinking ISPN transactions
> ----------------------------
>
> Key: ISPN-3927
> URL: https://issues.jboss.org/browse/ISPN-3927
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Labels: roadmap
>
> Umbrella JIRA for several transaction related improvements:
> -1. Async options for commit/rollback- (DONE)
> - they don't really make sense as a user you don't get any guarantee on the status of the transaction
> - they complicate the code significantly
> - I think they should be removed
> 2. READ_COMMITTED
> - it has the same performance as REPEATABLE_READ, but offers less guarantees.
> - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
> - I think it should be removed
> 3. Optimistic tx without Write Skew Check (WSC)
> - well, without WSC the transactions are not optimistic by definition
> - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
> - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
> - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
> 4. Remove 1PC option
> - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
> [1] http://markmail.org/thread/a7fjko4dyejxqgdy
> [2] https://github.com/infinispan/infinispan/pull/2177
> [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
> [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7528) Store CacheTransaction.keyRead(...) in RepeatableReadEntry
by Radim Vansa (JIRA)
Radim Vansa created ISPN-7528:
---------------------------------
Summary: 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)
9 years, 1 month
[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 updated ISPN-7526:
------------------------------
Summary: Write skew check throws even if the previous value was not read (was: Write skew fires even if the previous value was not read)
> 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)
9 years, 1 month
[JBoss JIRA] (ISPN-7527) Local write skew check cannot work with persistence
by Radim Vansa (JIRA)
Radim Vansa created ISPN-7527:
---------------------------------
Summary: 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)
9 years, 1 month