On Sat, Apr 28, 2012 at 5:29 AM, Emmanuel Lécharny <[email protected]> wrote: > Le 4/27/12 8:39 PM, Alex Karasulu a écrit : >> >> 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: >>> >>>> 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. > > That's an interesting decision to make... > > It's pretty obvious that OCC is the way to go when we have low data > contention, and this is excactly the case for a LDAP server. Being allowed > to process more than one update at a time, and with a low risk to see a > collision, that's a clear plus in this context. > > Now, the question is the added complexity of an OCC solution, compared with > a simple global lock over modification, assuming that we have a limited time > frame to implement the full OCC system. I am OK with going both ways. Just FYI, OCC solution is ready. Right now I am trying to handle this and that logical data cache consistency that people implemented over years.
> > Typically, as the server code continue to evolve fast, the longer we wait to > implement a valid solution on trunk, the more likely we wll have some huge > problems to merge. > > I stress out the fact that we are not facing a technical issue here, but > more a roadmap issue. > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
