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

Re: Search failure during update



On Mon, 28 Jan 2002, Kurt D. Zeilenga wrote:

> At 11:48 PM 2002-01-27, Michel.Minsoul wrote:
> >> At 08:20 AM 2002-01-23, Michel.Minsoul wrote:
> >> >Do you have any idea why the write and the read are not correctly
> >> >serialized by openldap in this case ?
> >> 
> >> By design, one requests are not serialized.  That is, the
> >> search may appear to have occurred before or after the add
> >> (but not during). 
> >> 
> >
> >OK, this is exactly what I expect from openldap.  The search must occur
> >before or after the update but not during. But the problem I have
> >encountered suggests that this is not what happens since the entry which
> >is updated exists BEFORE the update and still exists AFTER the
> >update. So why does the search fail randomly when it is started during the 
> >update. If the search was executed before or after, the search would always 
> >succeed since the entry always exists!
> 
> Well, on an up-to-date system, I'd assume the filter you asserted
> depended on the update.  If it wasn't, then I'd suspect you have
> corrupted indices.  In which, you should make sure you are running
> an up to date version of slapd and have completely rebuilt your
> indices after updating.
> 
> Kurt
> 

I have made new tests with different versions of openldap, on
different platforms and with different DB packages. In each cases, the
database was built from scratch with slapadd (from the same LDIF file) 
just before doing the concurency test I described in my first post
of this thread. This is what I get:

Platform	Openldap	LDBM		Binaries provider

AIX-4.3.3	2.0.11		gdbm-1.8	compiled myself
AIX-4.3.3	2.0.21		db-3.3.11	compiled myself
RedHat-7.2	2.0.21		db-3.2.9	compiled myself
RedHat-7.2	2.0.11		gdbm-1.8	rpm from RedHat dist

My test failed in all of the cases except in the last one (with the
openldap package provided by RedHat). In this case the lookup blocks 
until the end of the update and then returns the entry correctly.

I am really confused and don't know what I did wrong when I built the
package myself which could explain the problem. For the third case, which
is certainly a common environment, I simply executed configure without any 
options. Could someone explain what's going on ?

Regards,
Michel.