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