[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

I've created a JIRA to track this: https://issues.jboss.org/browse/ISPN-3730

On Nov 19, 2013, at 2:17 AM, Mircea Markus <mmarkus at redhat.com> 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? :-)
> 
> 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

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