At 12:40 AM 7/7/2007 +0200, Martin v. Löwis wrote: > > That wouldn't be necessary for this to become a problem. If PyPI was > > CGI before, then any sort of transient SQL problem wouldn't have had > > this effect, because the DB connection would've been closed at the end > > of each request. So, it's probably an existing SQL error in PyPI. > >That would be my guess. Another possibility might have been that >there was a Python exception, in which case PyPI would not have invoked >.commit on the transaction (so apparently, the transaction would have >been kept open). I'm unsure whether this might cause problems for >subsequent actions. Still, no such exceptions were reported... > >In any case, I now do a .rollback in the case of an exception, and >a .rollback before processing a new request. I'd like to get some >confirmation that this is a sensible approach (or what else best >practice is).
The best practice is ensuring that either a commit or rollback happens at the end of each web request that uses the connection. Then, there's no chance of a failed but not rolled-back transaction continuing to hold locks in the database. In PostgreSQL's case, the MVCC would prevent such a transaction from blocking any read-only transactions, of course. What you're doing is quite close to best practice; if I understand you correctly, it differs only in the case of what happens if there is a program error resulting in failure to commit or abort. _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
