[infinispan-dev] rethinking ISPN transactions

[Pedro Ruivo]

On 11/08/2013 03:28 PM, Mircea Markus wrote:
> Hey guys,
>
> Several things were discussed lately([1],[2],[3],[4]) around our transaction support. Here's some some thoughts I have around re-modeling transactions for 7.0:
>
> 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

+1

>
> 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

+1

>
> 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
>

-1 to drop it. it has the same semantic as pessimistic transactions (PT) 
and it doesn't make sense to remove OT without WS and keep PT without 
WS. IMO, or we drop PT and OT without WS or we keep it...

> 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 can you elaborate in which 1PC option are you talking about? (1pc 
for auto commit? 1PC for pessimistic transactions?)

>
>
> [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
>
>
> Cheers,
>