On 2008-04-25 09:40:01 +0100, Steve Kemp wrote: > I've seen problems with DBI under qpsmtpd, but I didn't pipe up > earlier because my symptoms are different than yours. > > I use a singleton module to gain access to the DBI instance,
That's a good idea. > code almost identical to this here (additional code added to > ensure the connection is ping()d and re-opened if it went away) > > http://yawns.repository.steve.org.uk/?file/tip/Singleton/DBI.pm > > All of my plugins have code like this: > > sub foo > { > my( $self, $transaction, $.... ) = ( @_); > > my $cache = Singleton::Memcached->instance(); > my $dbi = Singleton::DBI->instance(); > > ... > } > > This basic usage works just fine *unless* I try to update the > database. ie. SELECT queries are handled properly, always. > UPDATEs are not. > > Looking around I think that my problem is that qpsmtpd creates > the connection to the database prior to a fork - and that this > fork()d handle is copied around to the children causing issues. Well, qpsmtpd doesn't create the connection, your plugin does. 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. Or you could check for a changed pid in Singleton::DBI->instance() and open a new connection (*carefully* closing the old one). > Looking on perlmonks there are reports of people seeing random > problems if they fork() and use DBI without special care. Yes, of course. 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