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.