[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
h.b.furuseth@usit.uio.no wrote:
> Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE).
> I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though.
> (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if
> and only if rs.sr_entry->e_private != NULL. Which is possibly true with
> back-bdb but seems a shaky assumption in general.)
That is a requirement, yes. If you implement a backend that has cache/locking
constraints on its entries and you don't provide a pointer from the entry back
to your cache state, then you're an idiot. That means every time you want to
manipulate the cache state for that entry you'll have to do an expensive
search for it, instead of simply dereferencing e_private.
If you maintain private state for the entry, you point to it with e_private.
If e_private is not set, then there is no private state.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/