[Catalog-sig] psycoph errors from pypi
Phillip J. Eby
pje at telecommunity.com
Sat Jul 7 01:20:37 CEST 2007
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
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.
More information about the Catalog-SIG