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

 On Tue, 04 Oct 2011 18:47:21 -0600, Alex Rousskov wrote:
> On 10/04/2011 04:21 PM, Andrew Beverley wrote:
>> On Tue, 2011-10-04 at 18:59 +0100, Andrew Beverley wrote:
>>> > However, I'm now having problems with multiple instances of the
>>> session
>>> > helper writing to the same database. I thought I had fixed this
>>> with the
>>> > ->sync option, but it appears not. If I open multiple instances
>>> of
>>> > ext_session_acl in terminal windows on the same database, then I
>>> do not
>>> > get consistent results between each process. If I do a "LOGIN" on
>>> one,
>>> > then I can still get "No session available" on the other. Any
>>> ideas why
>>> > this might be? Is it a bug with db-185? Debugging shows that the
>>> key
>>> > does not exist in the second process, despite having been written
>>> in the
>>> > first.
>
>
>> After further investigation, the problem appears to be that the
>> *read*
>> database process is being cached (I'm not sure where). So even if
>> the
>> writing process syncs its changes to the DB file, these aren't
>> reflected
>> in the process that is reading the DB file.
>>
>> After a lot of Googling, the only way I can see to fix this is to
>> close
>> and re-open the database on every read. This is very messy, but does
>> anyone have any better suggestions?
>
> Hi Andrew,
>
> 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, 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.

 An upgrade is well overdue, but only really worth doing if this sync
 bug is fixed.

 Amos
Received on Wed Oct 05 2011 - 01:22:34 MDT