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.
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(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
>
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev