Re: [exim] dbm/dbmnz 'write' lookup?

Jakob Hirsch wrote:
> Quoting W B Hacker:
>
>>>> Is it possible to have Exim write to a dbm/dbmnz as part of a string
>>>> expansion or are only reads possible?
>> Not sure SQLLite is the best of the SQL's for 'sidestepping' the issue where
>> writes may be involved. ISTR it works against a file and has rather basic or
>> 'coarse grained' access locking.
>
> So what? This is about dbm vs. sqlite, not sqlite vs. other rdbms.

Well dbm style storage are *generally* used for 'write seldom, read often', and
SQLLite seems to be very good at that as well. That is not the issue.

> FWIW, there's a configurable lock timeout for sqlite (defaults to 5s),
> which should be sufficient as long as you are not excessively
> updating/inserting, which is unlikely in an MTA.
>

'...as long as..'

By definition, the OP (and I) are looking for a tool that might be called from
'lookup' style constructs, ergo the incidence of writes planned can be *expected
to be higher* than has been typical for the MTA where they have apparently not
been done *at all* with such tools. Else we would be discussing the spec or the
merits of prior posts, not still seeking.

Think AWL, Local Blacklisting, greylisting, passing ephemeral info about hosts,
recipients or messages. And more. Much more.

All such information is of the sort potentially used later in the same process,
or being read or added to by some other child process, or several such, at
*maybe* the same time. Not known how often or how predictably that might occur,
but we should plan for it.


> I'd even say, for most single host purposes sqlite could be faster than
> conventional RDBMSs.
>

Almost certainly true, and perhaps by a wide margin - for reads.

Less certain, and largely irrelevant, for multiple-sourced writes, where it is
the exception, not the average, that bites.

'always slower than..' <some alternative> is quite easy to live with in an MTA.

'may lock, timeout, or fail' <sometimes, maybe> is not as easy to manage.

Which brings us full-circle.

As supporting frequent inserts, updates, re-indexing from multiple
near-simultaneous processes (100 or more Exim child processes?) has not been
dbm's *primary* strength, perhaps that is a factor in the absence of the calls
sought?

Bill