I was recently trying this out with later versions of OpenLDAP 2.2.x
and discovered that something changed between 2.2.14 and 2.2.15 which
causes this approach to fail. While obviously the slapcat approach is
working, if be_entry_get_rw() is called from the main thread during
intialization, an EINVAL error is returned when trying to use a lock,
and the be_entry_get_rw() fails. Any ideas what may have changed to
cause this?
bdb(dc=example,dc=com): Locker does not exist
bdb_cache_entry_db_lock: entry 21, rw 0, rc 22
The code is something like this:
Operation op = {0};
Entry *entry = NULL;
op.o_tmpmfuncs = &ch_mfuncs;
op.o_bd = select_backend( &ndn, 0, 0 );
rc = be_entry_get_rw( &op, &ndn, objclass, attrdesc, 0, &entry );
-Jason
On Apr 28, 2004, at 8:05 PM, Howard Chu wrote:
-----Original Message-----
From: owner-openldap-devel@OpenLDAP.org
[mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Forest Hill
Thanks for your response, Kurt. After a bunch more hunting around,
I've basically come to same conclusion for when to do stuff, but the
how is proving more difficult. There are lots of places where
Operation's are constructed, but they all seem to have a ctx to start
with. All of the places that create a ctx seem to create it from an
existing ctx. How do I create a ctx, or is there a global ctx that
I'm supposed to use to genesis?
Look at back-bdb/tools.c; slapcat creates a pseudo-op in back-hdb
mode. There
are a couple of different "ctx" fields in the operation, it's not
clear what
you're talking about. Of course, it's a moot point - the threadctx
will be
retrieved if it's needed and not provided, and the tmpmemctx is purely
optional. If you don't provide a tmpmemctx then mallocs will all use
regular
malloc instead of temporary memory.
At 1:27 PM -0700 4/28/04, Kurt D. Zeilenga wrote:
At 02:49 PM 4/26/2004, Forest Hill wrote:
I'd like to store some config info in the database, with a
directive in the config file indicating where to look for that
config info. So, I need to search for the entry containing that
data after read_config() finishes, but before the server finishes
starting up.
Assuming the configuration information is database specific, then
one can do the search as part of the db_open(). If its overlay
specific, I believe one can overlay a db_open to do the search in.
If the configuration information is global, then you just need
to hack the startup to do additonal stuff post read_config()
but prior to starting the listener thread.
In regards to your second question, one just needs to construct
a pseudo-Operation to do the search under. There are a number of
examples of such in the code.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support