On Nov 12, 2013, at 12:43 PM, Martin Gencur <mgencur(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org