Description of problem:
Report from Ulf Weltman @ HP:
My Customer using Netscape Directory Server6.11.
This time, the problem of downing slapd happened frequently.
The result of the investigation by WTEC/LAB is as follows.
- As for slapd, when transaction-logging turned off,
writing in LDAP DB doesn't become threadsafe.
Because slapd is not threadsafe,
root cause of this problem that LDAP DB became corruption.
- This was confirmed to RedHat, that it was a specification of the
transaction-logging turned on to the fix action method.
but, My customer cannot consent in this specification.
My customer hopes it doesn't depend on the parameter,
and slapd writes it in LDAP DB in threadsafe.
The customer's request:
I want you to change the code of the product to become threadsafe
as writing in LDAP DB doesn't depend on the parameter of
I would say ramdisk transaction logs. I don't see any other way to provide
thread-safety with the performance they require. Especially if non-durable
transactions doesn't give them the necessary performance.
I recommended to Ulf when he asked about this that the customer put
their entire database in a ramdisk, or at least the transaction logs.
One thing to think about for the future: DB 4.4 has support for
purely in-memory transaction logging. This was designed to support
sleepycat's native single-master replication feature. But it's possible it'd
be useful for this kind of application.
They probably need something like the DS with a custom back-end
that uses Sleepycat HA and in-memory storage.
Dev team agrees with David's suggestion, moving to DB 4.4 in future release.