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.
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
