directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Question about JDBM key/value replacement
Date Fri, 27 Apr 2012 18:39:55 GMT
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

Mime
View raw message