Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 175339 - RFE: data integrity with logging disabled
RFE: data integrity with logging disabled
Product: Red Hat Directory Server
Classification: Red Hat
Component: Database - General (Show other bugs)
All Linux
medium Severity medium
: DS8.1
: ---
Assigned To: Noriko Hosoi
Chandrasekar Kannan
Depends On:
Blocks: 249650
  Show dependency treegraph
Reported: 2005-12-08 19:09 EST by Noriko Hosoi
Modified: 2015-01-04 18:19 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-03 09:46:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Noriko Hosoi 2005-12-08 19:09:47 EST
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
Comment 1 Noriko Hosoi 2005-12-08 20:10:25 EST
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. 
Comment 2 Noriko Hosoi 2005-12-08 20:12:32 EST
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.
Comment 3 To Ngan 2006-12-12 14:20:09 EST
Dev team agrees with David's suggestion, moving to DB 4.4 in future release.  

Note You need to log in before you can comment on or make changes to this bug.