Pierangelo Masarati wrote:

hyc@symas.com wrote:

...

Ah yes, that's correct. I misspoke - the DB is written when the cache has received an LDAP_RESULT from the remote server. The client gets this result when the cache has finished writing. We could move the DB write to a separate cleanup handler instead of running it in the response handler, which would free up the client sooner.

I also noticed that http://www.openldap.org/lists/openldap-devel/200708/msg00033.html, and I wanted to do something similar, but considering Ralf's observations, multiple clients concurrently running the same search request would cause it to be cached multiple times, because until the first one is not cached the others will not find it. OTOH, letting the others know it's being cached, and making them wait until caching is done would imply some delay, which could be long based on how many entries are being cached. However, given the purpose of a proxy cache, and considering that so many identical searches are not likely to occur simultaneously, I'd prefer to queue requests that are being cached.

Agreed. Even with a delay it ought to be faster than making the remote search again.

But this is probably not worth changing at this moment. Let's get 2.4.5 out first.