RE: simpler lockobj for back-bdb entry cache locking

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Jonghyuk Choi [mailto:jongchoi@us.ibm.com]

> When lockobj is changed from e_nname to e_id,
> 1% of db overhead is cut down from the execution trace
> (ftp://ftp.openldap.org/incoming/profile3.txt)
> and DirMark is up to 2381.2 ops/sec.
> The hashing function of BerkeleyDB seems performance sensitive
> to the key length. (__lock_ohash and __ham_func5)

Yah, I thought so. When we were first designing the locking approach I
figured by using the DN we could quickly prevent multiple attempts to Add or
ModRDN duplicate DNs. I'm not sure this is a valid concern now. At one time I
added code to ModRDN to lock the newDN while the operation was in progress,
but it didn't prove to be helpful  for avoiding clashes.

I'm also working out hierarchical entry cache code, so much of this will
change soon. No harm in using e_id as an interim step though.


  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support