[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/