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

[Pedro Ruivo (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)