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

[Mircea Markus (JIRA)]

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

Mircea Markus updated ISPN-3927:
--------------------------------

    Description: 
Umbrella JIRA for several transaction related improvements:
1. Async options for commit/rollback
- they don't really make sense as a user you don't get any guarantee on the status of the transaction
- they complicate the code significantly
- I think they should be removed

2. READ_COMMITTED
- it has the same performance as REPEATABLE_READ, but offers less guarantees. 
- unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
- I think it should be removed

3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition 
- they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
- suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
- build our batching functionality on top of what currently is optimistic tx without WSC and document it as such

4. Remove 1PC option
- I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing


[1] http://markmail.org/thread/a7fjko4dyejxqgdy
[2] https://github.com/infinispan/infinispan/pull/2177
[3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
[4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc

  was:
Umbrella JIRA for several transaction related improvements:
1. Async options for commit/rollback
- they don't really make sense as a user you don't get any guarantee on the status of the transaction
- they complicate the code significantly
- I think they should be removed

2. READ_COMMITTED
- it has the same performance as REPEATABLE_READ, but offers less guarantees. 
- unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
- I think it should be removed

3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition 
- they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
- suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
- build our batching functionality on top of what currently is optimistic tx without WSC and document it as such

4. Remove 1PC option
- I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing



    
> rethinking ISPN transactions
> ----------------------------
>
>                 Key: ISPN-3927
>                 URL: https://issues.jboss.org/browse/ISPN-3927
>             Project: Infinispan
>          Issue Type: Feature Request
>            Reporter: Mircea Markus
>            Assignee: Ion Savin
>             Fix For: 7.0.0.Final
>
>
> Umbrella JIRA for several transaction related improvements:
> 1. Async options for commit/rollback
> - they don't really make sense as a user you don't get any guarantee on the status of the transaction
> - they complicate the code significantly
> - I think they should be removed
> 2. READ_COMMITTED
> - it has the same performance as REPEATABLE_READ, but offers less guarantees. 
> - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
> - I think it should be removed
> 3. Optimistic tx without Write Skew Check (WSC)
> - well, without WSC the transactions are not optimistic by definition 
> - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
> - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
> - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
> 4. Remove 1PC option
> - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
> [1] http://markmail.org/thread/a7fjko4dyejxqgdy
> [2] https://github.com/infinispan/infinispan/pull/2177
> [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
> [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira