[Mailman3-dev] Re: [Mailman-Developers] Debate about Mailman on BytesForAll

[Richard Barrett]

On 26 Aug 2004, at 21:16, Barry Warsaw wrote:

> (Redirecting to Mailman3 list)
>
> On Thu, 2004-08-26 at 16:13, Kevin McCann wrote:
>
>> Might not make sense? Or might make sense?
>
> Might make sense to switch from BerkeleyDB to SQLite as the default
> embedded database for Mailman 3 (which BTW, I'm still happy to take
> primary responsibility for).
>
>> I have played with SQLite a
>> bit but not extensively, so I'm not aware of any major drawbacks. I do
>> recall at the sprint lunch that SQLite was suggested by that fellow 
>> who
>> was doing the email sprinting (can't remember his name, but he seemd 
>> to
>> be a sharp cookie). SQLite, if it's solid, is attractive to me because
>> it's built into PHP 5. Thinking down the road, it starts to look 
>> pretty
>> good.
>
> The biggest question in my mind is how SQLite handles concurrency
> issues.  I know that it has some support for concurrency, through
> automatic locking and such, but I haven't looked into the details.  
> This
> will be a requirement for MM3 because we'll have multiple processes
> reading and writing to the database all the time (web requests,
> qrunners, cron, command line, nntp, imap, etc., etc.).
>
> -Barry
>

I have not been involved in the debate what the database this thread is 
referring to is being used for, but, from what has been said above, 
might not Postgresql be a sound choice. Robust, proper transaction 
handling/concurrency, can run from NFS mounted or local storage, proper 
client/server operation, reasonable security. It may not be the easiest 
to install but ...

Another post to this list asked why NFS mounting of the database 
storage matters. Explanation for me: we have a large, high reliabilty, 
high availabilty,  etc etc file server accessible over Gigabit via an 
Extreme switch; we have an effective backup strategy for the file 
systems which that file server publishes via NFS. I currently use NFS 
storage with MM 2.1.x  and given a catastrophic hardware failure in my 
mailing list server I can switch to a backup server and have full 
service back within minutes without data loss. We are putting a large 
value of e-trading messages through the mailing list server each week 
and some of that incoming traffic has strict time limits on when 
responses are sent; we cannot accept loss of service. Why would I want 
to buy into the admin problems of being compelled to run a database out 
of storage local to my mail list server? Which is why BerkeleyDB does 
not look like the right solution for me. For the same reason I also 
cannot use Subversion for its purposes, even though I would rather like 
to.

Just a thought.