we would remove the conflict detection and txn retry in case of
On Fri, Apr 27, 2012 at 9:46 AM, Emmanuel Lécharny <firstname.lastname@example.org
> Le 4/27/12 6:35 PM, Selcuk AYA a écrit :
>> On Fri, Apr 27, 2012 at 9:08 AM, Emmanuel Lécharny<email@example.com
>>> We don't really care if that serialize the modifications, because the
>>> does not have to be fast when we inject data, only when we read data. At
>>> least, we could think about a serialization over the operations on one
>>> like the RdnIndex (as an entry modification may update more than one
>>> in this index).
>>> Is that a problem ?
>> Depends. What I have been describing in the emails and trying to
>> implement is an optimistic locking scheme where modifications can go
>> in parallel unless they conflict. It seems we could just get a big
>> lock for write txns rather than dealing with optimistic concurrency
> Ok, I see.
> What would be the impact on the txn branch if we fallback to such a system ?