On Wed, 05 Oct 2011 23:41:54 +0100, Andrew Beverley wrote:
> FWIW, the ssl_crtd daemon which stores generated SSL
certificates
> on
> disk does [lock and] reopen the database every time it needs to
read
> it.
> This is not efficient, but avoids conflicts and stale info.
>
> If you do not like that simple but inefficient approach,
It was more that I thought it wouldn't get past the stringent Squid
developers ;-)
you can use
> a
> better database that can handle concurrency (and leave all caching
to
> it) OR implement your own custom and efficient database,
possibly
> using shared memory.
>
> Disclaimer: I do not remember what database the session helper is
> using
> so I may be overlooking simpler/better options.
An ancient version of BerkleyDB. Mostly because the *.db API became
much less simple and potentially slower in later versions.
I think that in reality, on modern systems, it uses the same library,
but in "1.85 compatibility mode".
An upgrade is well overdue, but only really worth doing if this
sync
bug is fixed.
I have tried using the same functions on the modern API: this didn't
fix
the problem (probably because it is just running in compatibility
mode).
I then tried the modern API, but using the added features (DB_ENV).
This
*does* fix the problem.
Hurrah.
So, I propose that the session helper is upgraded to both the new API
and to use the DB_ENV functionality. I will write the patch. Any
objections?
Please.
The current session helper appears to allow the inclusion of both
db_185.h and db.h. However, if the latter is included, it generates
lots
of compilation errors because the API has changed. The question is:
can
we just remove the reference to db_185.h and write the code for the
modern API (with the sync fixes), or do you want to keep the option
to
use db_185? The latter will require several #IF statements to select
the
correct code for the API. I would prefer to just remove it.
I think 1.85 is so ancient now its not really needed for old-OS
support. The problem is more likely to be adding #if to support db.h and
4.2 or such for RHEL.
Aiming for the latest API with wrappers for currently aging-out
versions will give the longest forward-compatible period before anyone
needs to touch it again.
Amos
