Howard Chu writes:
Unfortunately I realized that not all application-level caching can be eliminated - with the hierarchical DB approach, we don't store full entry DNs in the DB so they still need to be generated in main memory, and they probably should be cached. But that's a detail to be addressed later; it may well be that the cost of always constructing them on the fly (no caching) is acceptable.
I previously complained that an mmapped database with no level of caching in the code would collect the effects of bugs quite efficiently. If some other module incorrectly modifies an entry in-memory when it should have modified a private copy, the mod goes directly to the DB even if nothing is doing an LDAP update operation. Restarting slapd does not clean up, slapcat/slapadd may not work either. Is there something in this design which fixes that?