Bug 175339 - RFE: data integrity with logging disabled
Summary: RFE: data integrity with logging disabled
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Database - General (Show other bugs)
(Show other bugs)
Version: 6.21
Hardware: All Linux
medium
medium
Target Milestone: DS8.1
: ---
Assignee: Noriko Hosoi
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 249650
TreeView+ depends on / blocked
 
Reported: 2005-12-09 00:09 UTC by Noriko Hosoi
Modified: 2015-01-04 23:19 UTC (History)
4 users (show)

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


Attachments (Terms of Use)

Description Noriko Hosoi 2005-12-09 00:09:47 UTC
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.

Comment 1 Noriko Hosoi 2005-12-09 01:10:25 UTC
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-09 01:12:32 UTC
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 19:20:09 UTC
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.