[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

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? :-)

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)