[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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
- note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails.
[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- (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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
[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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> 6. Internal changes
> - remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
> 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
> 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
> - note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails.
> [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)
7 years, 9 months
[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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list of {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
- note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails.
[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- (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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
- note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails.
[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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> 6. Internal changes
> - remove list of {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
> 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
> 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
> - note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails.
> [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)
7 years, 9 months
[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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
[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- (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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache
[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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> 6. Internal changes
> - remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
> 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache.
> 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.
> [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)
7 years, 9 months
[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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache
[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- (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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache (see ISPN-5600 below)
[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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> 6. Internal changes
> - remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
> 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache
> [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)
7 years, 9 months
[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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
6. Internal changes
- remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache (see ISPN-5600 below)
[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- (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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
[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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> 6. Internal changes
> - remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation.
> 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache (see ISPN-5600 below)
> [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)
7 years, 9 months
[JBoss JIRA] (ISPN-7621) as-lucene-directory integration tests need to cleanup the testing database
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-7621:
-------------------------------------
Summary: as-lucene-directory integration tests need to cleanup the testing database
Key: ISPN-7621
URL: https://issues.jboss.org/browse/ISPN-7621
Project: Infinispan
Issue Type: Task
Components: Test Suite - Query
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 9.0.0.Final
The WildFly configuration used by the {{as-lucene-directory}} integration tests uses a DataSource connection to the H2 testing database which is configured for on-disk persistence in the ~ home path.
This makes subsequent runs of the testsuite fail as there's unexpected data in the database already.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
[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- (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
> 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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> [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)
7 years, 9 months
[JBoss JIRA] (ISPN-7620) Add metadata to Cache Stores
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7620:
----------------------------------
Summary: Add metadata to Cache Stores
Key: ISPN-7620
URL: https://issues.jboss.org/browse/ISPN-7620
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 9.0.0.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
We should add metadata to store implementations to allow existing stores to be validated at startup.
This metadata should at least contain the Infinispan version used to write to the store, so that we can present the user with better errors if incompatibilities exist between different versions.
We could also write include information about which marshaller was used to read/write the data originally.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months