[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: multiple subordinates and shm_key - not a good idea

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org [mailto:owner-openldap-
> software@OpenLDAP.org] On Behalf Of matthew sporleder
> Sent: Thursday, April 27, 2006 10:15 AM
> To: Quanah Gibson-Mount
> Cc: OpenLDAP Software List
> Subject: Re: multiple subordinates and shm_key - not a good idea
> On 4/27/06, Quanah Gibson-Mount <quanah@stanford.edu> wrote:
> > Quoting matthew sporleder <msporleder@gmail.com>:
> >
> > As a side note, I assume you patched BDB 4.4.20 with the two patches
> > released by sleepycat, right? :)
> >
> Umm.. no.  But I'm recompiling now.
> Maybe this is the culprit:
> http://dev.sleepycat.com/resources/faq_show.html?id=114

Not very likely, unless you are invoking db_recover in a startup script or
something like that. OpenLDAP 2.3.x goes to great pains to 1) Recover the
database when recovery is needed and it is OK to do so (no other process has
the DB env open), 2) NOT recover the database when recovery is NOT needed
(all processes using the DB closed it cleanly), and 3) NOT recover the
database if it is necessary but some other process still has it open,
thereby avoiding corrupting the database. For further information see the
alock code and its use in back-bdb and back-hdb.

Incidentally, it was speculated that the advent of the DB_REGISTER call
offered by BDB 4.4 would eliminate the need for back-bdb/back-hdb to perform
recovery arbitration, but this is not the case. Although DB_REGISTER does
some of what alock does, it doesn't do everything that's needed by OpenLDAP.
A thread discussing the complete design behind alock is here: 



Matthew Hardin
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: