On 2008-04-25 11:00:22 +0100, Steve Kemp wrote: > On Fri Apr 25, 2008 at 11:13:09 +0200, Peter J. Holzer wrote: > > Well, qpsmtpd doesn't create the connection, your plugin does. > > Indeed. > > > DBI connections generally cannot be shared between processes (not even for > > selects, if it worked for you, you were just lucky), so you need to make > > sure you don't create the connection before the connect hook. > > I don't, thankfully.
I presume that "I don't" means "I don't create the connection before the
connect hook", not "I don't make sure ...". But then you shouldn't get
shared connections and everything should work ok.
> > Or you could check for a changed pid in Singleton::DBI->instance()
> > and open a new connection (*carefully* closing the old one).
>
> That is an option. In the end I decided to just the avoid updates from
> within the qpsmtpd process.
This isn't safe.
> Generally my DBI queries are of the form "Does this domain want
> to run antivirus?", or "does this user exist?". The updates are handled
> via a web application. The only part that caused me pain was having
> a database-backed IP blacklist.
>
> Testing worked OK ( "SELECT ip,reason FROM blacklists WHERE ip=?" ),
You were just lucky. Consider the case where two clients connect at the
same time. Two qpsmtpd processes will sent the query to the database
over the same connection and then wait for the answer. When the server
answers it is completely arbitrary which qpsmtpd processe will receive
the answer. One process might get both answers (causing the other to
hang), each one might get the answer intended for the other one, or they
might each get some random pieces of the answers.
Sure, under low load it will work almost always. But only almost.
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | [EMAIL PROTECTED] | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature
