RE: back-bdb DB_RECOVER and soft restart

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Hallvard B Furuseth

> Matthew Hardin writes:
> >>From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]

> >> Why get a read lock when you already have a write lock?
> >
> > (...) Demoting a write lock to a read lock (...)

> Oh... that was the point I was missing.  But if a file
> descriptor has a
> write lock, are you sure that acquiring a read lock will lose
> the write
> lock?  On all operating systems that use Berkeley DB, and all kinds of
> locks OpenLDAP might use?

File locks are always one lock per process. If you have a write lock and you
acquire a read lock, the write lock is necessarily demoted because a single
process cannot have both on the same target. Also a locker can never block
itself, so you cannot block when trying to demote a write to a read lock.
This operation will always succeed.

> >> Besides, if you will use
> libraries/liblutil/lockf.c:lutil_lockf, that
> >> may use lockf() which only supports 'locks', not
> 'read/write locks'.

lutil_lockf() itself is not flexible enough for this purpose. We will
probably have to add code to lockf.c since the existing routines are meant to
lock a whole file, and don't allow specifying whether to wait or not. We
really need the functionality of fcntl (byte range locks, read or write) to
make this work, otherwise we'll have to use multiple lock files.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support