Re: [PATCH] Re: Adding a reset option to the session helper

From: Andrew Beverley <andy_at_andybev.com>
Date: Wed, 05 Oct 2011 23:41:54 +0100

> > 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.

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?

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.

Andy
Received on Wed Oct 05 2011 - 22:42:02 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 06 2011 - 12:00:04 MDT