directory-dev mailing list archives

On Sat, Apr 28, 2012 at 5:29 AM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
> Le 4/27/12 8:39 PM, Alex Karasulu a écrit :
>>
>> 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:
>>>
>>>> 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
>