Re: apr_dbm and concurrency

> On 9 Nov 2023, at 16:15, Greg Stein <[email protected]> wrote:
> 
> Personally, I'd deprecate apr_dbm entirely, and direct all clients towards sqlite.
> 
> The DBMs were intended for simple key/value stores 20 years ago. We have much better tech now. Sqlite does K/V so much better, *and* it handles processes/threads. I really don't see a reason for DBM nowadays.
> 
> Who can justify using (say:) ldbm over sqlite?

Legacy apps?  I first used ndbm more than 30 years ago.  Software from
that era is still in use, and might crop up in someone's work today.
I *think* I even wrote about the apr_dbm concurrency issue long ago,
in an era when non-thread-safe libraries were being adopted willy-nilly
and to point it out was to be labelled a stick-in-the-mud enemy of progress.

+1 to deprecting apr_dbm, provided we explain exactly why (so users
are clear whether or not it matters to their use cases).  The alternative would
be smart locking code within apr_dbm, and I doubt that anyone wants to
put that effort in.

Applications can still use a dbm of their choice without the APR layer.

-- 
Nick Kew