Hide Forgot
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 product. 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 transaction-logging.
rmeggins wrote: 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.
dboreham wrote: 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.