[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years