[Date Prev][Date Next]
RE: commit: ldap/servers/slapd/back-bdb add.c modify.c modrdn.c
The prepare actually frees all read locks but not write locks. I was seeing a
BDB error from modrdn, which initially grabs a read lock on the cached entry.
In bdb_cache_modrdn there is a call to reacquire this as a write lock, but
the read lock no longer existed. I note that the prepare call had already
been removed from the bdb_modify and bdb_delete code, I was just bringing Add
and Modrdn into line with that.
All of these operations were already using nested transactions. All of the
database modifications were already committed in the child transaction, so
presumably we already know that the parent commit will succeed.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, December 24, 2003 8:17 AM
> To: hyc@OpenLDAP.org
> Cc: OpenLDAP Commit
> Subject: Re: commit: ldap/servers/slapd/back-bdb add.c
> modify.c modrdn.c
> I don't have code handy (I'm on holiday) but note that I
> purposely put in a prepare before commit so that I could
> do something after the prepare but before the commit
> without worry that commit could fail. However, you're
> saying that prepare frees all the locks. This seems odd
> since the BDB needs to be prepared for an abort which
> would require those locks.
> At 04:27 AM 12/24/2003, hyc@OpenLDAP.org wrote:
> >Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb
> >Modified Files:
> > add.c 1.99 -> 1.100
> > modify.c 1.97 -> 1.98
> > modrdn.c 1.131 -> 1.132
> >Log Message:
> >ITS#2895 TXN_PREPARE is not needed since we use nested
> transactions. It
> >also has a side-effect of releasing all the transaction's
> existing locks.
> >CVS Web URLs:
> > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/
>Changes are generally available on cvs.openldap.org (and CVSweb)
>within 30 minutes of being committed.