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

 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
Received on Wed Oct 05 2011 - 23:08:05 MDT