[infinispan-dev] rethinking ISPN transactions

[Sanne Grinovero]

On 12 November 2013 12:31, Radim Vansa <rvansa at redhat.com> wrote:
> Yet one more request: clear behaviour should be specified there as well
> - there was some discussion about txs and clear few months ago (I think
> fired by Sanne), but I have a feeling that it just got burried in the
> mailing list without any concrete result.

+1
thanks for the reminder: I'm still waiting for closure on that too.

Sanne

>
> Radim
>
> On 11/12/2013 01:26 PM, Radim Vansa wrote:
>> 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.
>>
>> 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 at 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 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
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev