[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/servers/slapd/back-bdb add.c back-bdb.h bind.c cache.c compare.c config.c delete.c dn2entry.c dn2id.c filterindex.c id2entry.c idl.c init.c key.c modify.c modrdn.c proto-bdb.h referral.c search.c tools.c

To: Howard Chu <hyc@symas.com>
Subject: Re: commit: ldap/servers/slapd/back-bdb add.c back-bdb.h bind.c cache.c compare.c config.c delete.c dn2entry.c dn2id.c filterindex.c id2entry.c idl.c init.c key.c modify.c modrdn.c proto-bdb.h referral.c search.c tools.c
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Thu, 25 Sep 2008 14:23:55 +0200
Cc: OpenLDAP Commit <openldap-commit2devel@openldap.org>
In-reply-to: <48DB7CF9.5020309@symas.com>
References: <200808262345.m7QNja8I039284@cantor.openldap.org> <48B4966F.2080504@symas.com> <48B5B3E0.3050700@symas.com> <48DB7CF9.5020309@symas.com>

Howard Chu writes:
> My approach for that was to set the NOWAIT flag on the read txns, but
> that eats up too much CPU because most of our code immediately retries
> whenever it sees the DB_LOCK_NOTGRANTED result. I've removed the
> NOWAIT flag again. Still looking at the impact of this change.

Is this the kind of situation where it can help to retry at increasing
and somewhat randomized intervals until it succeeds?
(Randomized so two threads won't keep getting in each others' way.)

-- 
Hallvard

Follow-Ups:
- Re: commit: ldap/servers/slapd/back-bdb add.c back-bdb.h bind.c cache.c compare.c config.c delete.c dn2entry.c dn2id.c filterindex.c id2entry.c idl.c init.c key.c modify.c modrdn.c proto-bdb.h referral.c search.c tools.c
  - From: Howard Chu <hyc@symas.com>

References:
- Re: commit: ldap/servers/slapd/back-bdb add.c back-bdb.h bind.c cache.c compare.c config.c delete.c dn2entry.c dn2id.c filterindex.c id2entry.c idl.c init.c key.c modify.c modrdn.c proto-bdb.h referral.c search.c tools.c
  - From: Howard Chu <hyc@symas.com>