> 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
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
But this is probably not worth changing at this moment. Let's get 2.4.5 out first.
-- Howard Chu
Chief Architect, Symas Corp.