[Date Prev][Date Next]
Re: back-bdb concurrency
>With shared locks in BDB, it has been possible for multiple processes to
>operate on the same database at once. I frequently took advantage of this
>running slapadd while slapd is running. But with IDL caching in the
>back-bdb, this is no longer advisable for slapadd, as there is no means in
>slapd to detect that the underlying IDLs have changed. slapcat is still
Thanks for pointing out this.
I first considered comparing the numbers of IDs in memory and DB IDL.
Because bdb_idl_fetch_key is on the critical path, a single c_get and
to get the DB IDL size affects search performance. For the most cases where
slapadd is run not so frequently, how about having a signal based solution
making slapd invalidate its idl cache upon receiving a signal from slapadd