January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3927: -------------------------------- Description: 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 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 > rethinking ISPN transactions > ---------------------------- > > Key: ISPN-3927 > URL: https://issues.jboss.org/browse/ISPN-3927 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Ion Savin > Fix For: 7.0.0.Final > > > 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 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3927: -------------------------------- Fix Version/s: 7.0.0.Final > rethinking ISPN transactions > ---------------------------- > > Key: ISPN-3927 > URL: https://issues.jboss.org/browse/ISPN-3927 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Ion Savin > Fix For: 7.0.0.Final > > > 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 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3927: ----------------------------------- Summary: rethinking ISPN transactions Key: ISPN-3927 URL: https://issues.jboss.org/browse/ISPN-3927 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Ion Savin 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 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3736) Backport to 5.2.x for EAP 6.3

by Marek Novotny (JIRA)

[ https://issues.jboss.org/browse/ISPN-3736?page=com.atlassian.jira.plugin.... ] Marek Novotny commented on ISPN-3736: ------------------------------------- [~rhusar] and [~dan.berindei] it was originally linked due https://bugzilla.redhat.com/show_bug.cgi?id=1036889 and it depend on ISPN update 5.2.8.Final, so I can't say what the exact JIRA issue is that, but linked https://bugzilla.redhat.com/show_bug.cgi?id=999354 is the right one, which needs to be fixed/back ported. > Backport to 5.2.x for EAP 6.3 > ----------------------------- > > Key: ISPN-3736 > URL: https://issues.jboss.org/browse/ISPN-3736 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.2.7.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Fix For: 5.2.8.Final > > > This JIRA will track the issues that need to be backported to the 5.2.x branch for EAP 6.3. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3926) The ClusterRegistry needs to be persistent

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3926?page=com.atlassian.jira.plugin.... ] Adrian Nistor edited comment on ISPN-3926 at 1/24/14 8:23 AM: -------------------------------------------------------------- We need a share cached store. was (Author: anistor): We need a share cache store. > The ClusterRegistry needs to be persistent > ------------------------------------------ > > Key: ISPN-3926 > URL: https://issues.jboss.org/browse/ISPN-3926 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Several improvements suggested by Sanne: > - protobuf schemas should be persisted, hotrod topology info and security cache should not > - also for security I want to set lifetime properties -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3736) Backport to 5.2.x for EAP 6.3

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-3736?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on ISPN-3736: -------------------------------------- Dan, [~manaRH] linked that issue probably as an attempt to find the cause. Any chance it rings a bell being an ISPN issue that is not linked that could be backported? > Backport to 5.2.x for EAP 6.3 > ----------------------------- > > Key: ISPN-3736 > URL: https://issues.jboss.org/browse/ISPN-3736 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.2.7.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Fix For: 5.2.8.Final > > > This JIRA will track the issues that need to be backported to the 5.2.x branch for EAP 6.3. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3926) The ClusterRegistry needs to be persistent

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3926?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3926: ------------------------------------- We need a share cache store. > The ClusterRegistry needs to be persistent > ------------------------------------------ > > Key: ISPN-3926 > URL: https://issues.jboss.org/browse/ISPN-3926 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Several improvements suggested by Sanne: > - protobuf schemas should be persisted, hotrod topology info and security cache should not > - also for security I want to set lifetime properties -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3926) The ClusterRegistry needs to be persistent

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3926?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3926: ------------------------------------- Maybe we could use separate caches per scope? > The ClusterRegistry needs to be persistent > ------------------------------------------ > > Key: ISPN-3926 > URL: https://issues.jboss.org/browse/ISPN-3926 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Several improvements suggested by Sanne: > - protobuf schemas should be persisted, hotrod topology info and security cache should not > - also for security I want to set lifetime properties -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3926) The ClusterRegistry needs to be persistent

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3926?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3926: ------------------------------------- [~anistor] The cache could always be configured to be persistent with the SingleFileCacheStore and the user should be able to specify the file location.. > The ClusterRegistry needs to be persistent > ------------------------------------------ > > Key: ISPN-3926 > URL: https://issues.jboss.org/browse/ISPN-3926 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Several improvements suggested by Sanne: > - protobuf schemas should be persisted, hotrod topology info and security cache should not > - also for security I want to set lifetime properties -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3926) The ClusterRegistry needs to be persistent

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3926?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3926: ------------------------------------- Currently the config for the cluster registry cache is hardcoded. So there is not way for the user to configure a cache store. Also, persisting just some scopes and not the other is not going to work. > The ClusterRegistry needs to be persistent > ------------------------------------------ > > Key: ISPN-3926 > URL: https://issues.jboss.org/browse/ISPN-3926 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Several improvements suggested by Sanne: > - protobuf schemas should be persisted, hotrod topology info and security cache should not > - also for security I want to set lifetime properties -- 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, 2 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 January 2014