On Fri, Apr 27, 2012 at 8:11 PM, Selcuk AYA <[email protected]> wrote:
> On Fri, Apr 27, 2012 at 9:46 AM, Emmanuel Lécharny <[email protected]> > wrote: > > Le 4/27/12 6:35 PM, Selcuk AYA a écrit : > >> > >> On Fri, Apr 27, 2012 at 9:08 AM, Emmanuel Lécharny<[email protected]> > >> 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
