[infinispan-dev] rethinking ISPN transactions

[Galder Zamarreño]

On Nov 12, 2013, at 12:43 PM, Martin Gencur <mgencur at redhat.com> wrote:

> +1 for all these suggestions. Configuring transactions in Infinispan is 
> overly complex (too many options). Some of the configurations were 
> supposed to provide better performance and they actually don't provide 
> that, some of them degrade transactions to non-transactions, people 
> cannot get the confidence of data consistency. This will also save 
> users' time when running perf. tests to verify which configuration is 
> faster, by providing fewer options.

+1000. We should use this to reduce the configuration options :)

> 
> Martin
> 
> 
> On 8.11.2013 16:28, 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
>> 
>> 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
>> 
>> 
>> Cheers,
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org