Re: [Exim] Persistent DB connections to MySQL database

> > First let me say that Exim is the greatest MTA ever created...
>
> Thank you. When I read a paragraph like that, I know that the next one
> is going to be something like
>
> > That said, I'd like to make a feature request,
>
> Yup... :-)

True, but I really really mean it.


> For the very fastest performance, I would think you would do better to
> abstract the relevant data from your DB or LDAP, and build local cdb
> files for Exim to work off. Of course, this gives a delay between making
> a database change and its taking effect, but you can arrange for that to
> be relatively short. It also means that mail continues to flow when the
> database is down.

You know, I've been putting off doing exactly that (dumping to cdb files)
for much too long. Sounds like today's a good day to start :)


> Another disadvantage, of course, is that if your central DB caching
> process goes wrong, or crashes, you've killed all mail delivery. With
> the current Exim design, if one process has problems, it does not affect
> the rest. The daemon is the only process that is vulnerable in this
> sense, and even then, it affects only incoming messages. As its job is
> well defined and doesn't change, the daemon code isn't edited very
> often.
>
> I just don't like putting all the eggs in one basket. Or even a small
> number of baskets.
>
> > And heck, while I'm day-dreaming, any chance of being able to tune the
> > size of the cache?
>
> The cache is only per-process. It is not inter-process.
>
> Consider again my suggestion above about abstracting relevant data from
> your DB and sticking it in cdb files. You could write a permanently
> running process that does this every 30 minutes or whatever (or when
> prodded). This could keep open a permanent connection to the database.
> You could even arrange for it to watch a field in the database that told
> it when to rebuild which files. If you do this, the cdb files are your
> inter-process cache, and on a busy system their blocks will be in main
> memory most of the time - let the OS do flexible caching for you,
> according to the amount of free memory. The interlocking between Exim
> processes is then only at the filesystem level, and the OS is good at
> handling that kind of contention.

All excellent points. I think I'll give it a try. Thanks for the speedy
reply and again, thanks for exim.