[Catalog-sig] psycoph errors from pypi

[Phillip J. Eby]

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.