On Fri, Apr 27, 2012 at 8:11 PM, Selcuk AYA <ayaselcuk@gmail.com> wrote:
On Fri, Apr 27, 2012 at 9:46 AM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
> Le 4/27/12 6:35 PM, Selcuk AYA a écrit :
>> On Fri, Apr 27, 2012 at 9:08 AM, Emmanuel Lécharny<elecharny@gmail.com>
>>  wrote:
>>> We don't really care if that serialize the modifications, because the
>>> server
>>> 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
>>> index
>>> like the RdnIndex (as an entry modification may update more than one
>>> entry
>>> 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
>> control.
> Ok, I see.
> What would be the impact on the txn branch if we fallback to such a system ?

we would remove the conflict detection and txn retry in case of
conflicts and change how RW txns are handled.

> What also would be the impact on the current code, assuming that we update
> many elements on the RdnIndex, so that the optimistic locking scheme keeps
> working ?

You know this better. If trying to maintain optimistic locking
adversely affects searches and we are OK with outstanding RW txn(this
includes all the operations in the interceptor chain in case of a
add/delete/modify), then we should get rid of optimistic locking.

IMO I don't think we should get rid of optimistic locking. 

Best Regards,
-- Alex