Bug 175339 – RFE: data integrity with logging disabled

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

Summary:	RFE: data integrity with logging disabled

Status:	CLOSED WONTFIX

Aliases:	None

Product:	Red Hat Directory Server
Classification:	Red Hat
Component:	Database - General (Show other bugs)
Sub Component:
Version:	6.21
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	DS8.1
Target Release:	---
Assigned To:	Noriko Hosoi
QA Contact:	Chandrasekar Kannan
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:	249650
	Show dependency tree / graph

Reported:	2005-12-08 19:09 EST by Noriko Hosoi
Modified:	2015-01-04 18:19 EST (History)
CC List:	4 users (show)

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

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: 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
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-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.