Roundup Tracker - Issues

Message4425

Author mpm
Recipients ber, mpm
Date 2011-09-16.16:21:13
Message-id <1316190073.94.0.753490101055.issue2550727@psf.upfronthosting.co.za>
In-reply-to
We get this on the Mercurial project when we close bugs in commit
messages. We have a robot that scans each commit for the close signature
and fires off an email to our bts mail gateway. Each message to the
gateway starts a separate roundup process.

We hit this race quite consistently. I think this is helped by Postfix,
which scans its input queues on a timer, and thus consistently fires off
messages simultaneously on different cores.

As I understand sqlite3/pysqlite's locking model, pysqlite opens the
database in shared mode and automatically opens and closes transactions
for certain kinds of SQL statements. So we end up with multiple
processes looking up the msgid simultaneously, adding one, then doing
write transactions (that succeed). Then we next go on to try to insert
two messages with the same message id and fail on the second one.

There's nothing anywhere in the sqlite backend that looks like locking.
History
Date User Action Args
2011-09-16 16:21:13mpmsetmessageid: <1316190073.94.0.753490101055.issue2550727@psf.upfronthosting.co.za>
2011-09-16 16:21:13mpmsetrecipients: + mpm, ber
2011-09-16 16:21:13mpmlinkissue2550727 messages
2011-09-16 16:21:13mpmcreate