According to Brian Grossman:
>
> My big reason for wanting to do it in the first place was to avoid locking
> issues. Locking in mj1 is horrible. Avoidance of locking issues,
> especially if also addressed in the mj2 daemon's queueing would let mj2
> scale to multiple machines.
>
> Using berkeley db is essentially the same as idea one. It should be
> sufficient in all but the most demanding applications.
I would think that besides the locking issue the real win in using
a backend database would come from letting it provide the list
ordered by domain with duplicate users removed so MD can hand
it off to sendmail in reasonable sized chunks that will deliver
messages to the same host in one connection. Something like:
select distinct user, domain from list order by domain, user;
is almost certainly going to run faster in a relational
database with proper indexes than you can do it in perl. (You
do need to smash the case on domain somehow).
This could be done with DBI and anyone whose lists are small
enough that the performance doesn't matter could use DBD::CSV
without having to install a database server that runs as a
separate process. Of course I've been too lazy, err.. busy
to try this myself, although I have manually emulated it a
few times to get a huge list into shape.
Les Mikesell
les@mcs.com
References:
|
|
