Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional modes and *expected
behaviour*? (using short code snippets: in one mode this will fail, in
other one succeed) Ideally, total order could be included there as well.
total order does not change the "behaviour" of the transactional mode.
it only change how the transactions are committed but the semantics are
the same...
This list should provide the rationale for each mode. Maybe I could then
provide some numbers for each mode to let user see whether the lower
guarantees are worth the performance impact.
Also, I'd like to see there presented the problem with transactional
reads - to let users know that if you write two values inside the
transaction and commit it, in another transaction you may read one of
the entries as appeared before the commit and another as appeared after.
I know that this can be evaded by force locking, and I understand why
this happens but when user reads /transactions/, he sees /ACID
properties/. And this (default) unexpected behaviour kind of breaks
isolation - user needs to be aware of that (and I haven't seen this
written down anywhere in the docs).
Radim
On 11/12/2013 12:56 PM, Galder ZamarreƱo wrote:
> On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)redhat.com> 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
> So, they're always sync, right?
>
>> 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. So, if you remove RC, and we only have RR, you can get rid of the isolation level
configuration property altogether? We don't implement SERIALIZABLE, nor
READ_UNCOMMITTED.
>
>> 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)
> +1
>
> FYI, this means that the default OL behaivour changes. To be more precise, here's
[1] a Gist with the difference in expectations for default configuration.
>
> [1]
https://gist.github.com/galderz/9ba22e47116906a750d7
>
>> - 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
>
>>
>> [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,
>> --
>> Mircea Markus
>> Infinispan lead (
www.infinispan.org)
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev