[infinispan-dev] rethinking ISPN transactions

[Pedro Ruivo]

On 11/19/2013 02:17 AM, Mircea Markus wrote:
>
> On Nov 12, 2013, at 3:12 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>> On 11/12/2013 11:56 AM, 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.
>>
>> actually, I have plans to introduce UPDATE-SERIALIZABLE consistency :)
>
> I never get my head around this: what's the difference between UPDATE-SERIALIZABLE and one-copy serializable? :-)

update serializable allow 2 read-only transactions to observe different 
commit orders of non conflicting transaction in their history.

>
> Cheers,
>