The Problem

From Richard Clark's initial post on the above mentioned thread:

After a random interval running, anything between 5 minutes and a day,
the app concerned will stop responding to requests - ie, all in-
progress or new requests will simply hang. An strace indicates the
process is waiting on a futex, which suggests some kind of lock
acquire jamup.

The Diagnosis

From Jason's final post on the thread:

It's a bug in SQLObject. We're using an old version, but the same code is
in the newer versions too.

Below is an explanation of the issue.

Postgres has all sorts of locks that are created when you do many different
things. The threadSafeMethod also creates a lock, but this one is local to
a single python process.

Let's go over an example. You have two threads (A and B) that are in the
middle of different db transactions. Thread A has locks on tables I and

Thread B creates a row on table III that has a foreign key to table I,

it will wait for thread A's lock to be given up before actually creating
that row. Then if thread A gets context again and tries to create or
access a row in table III it will lock because of the threadSafeMethod's
lock.

Postgres will see one thread trying to create a row and the other thread
(the one that the former thread is waiting for a lock from) idle in
transaction. Neither one will continue doing anything.

Usually other requests come in so new threads pick them up and try to query
tg-visit, but the db has certain types of locks on tg-visit rows so those
threads end up waiting for thread A and thread B to give up, even though
they never will.

It turns out that the code (see below - Ed.) was originally put into SQLObject on Alberto's
request:

It appears that the code section (in class DeclarativeMeta) containing the line from the above mentioned fix does not exists any more in the latest trunk version (revision 3396) of declarative.py. It is still present in the latest release version of SQLObject (10.0) though. Can someone confirm that this issue still exists when using SQLObject from SVN?

Are we ok to bump up the SQLObject dependency for TG 1.0 and 1.1 to this version? I get no (db-related) test failures in TG 1.0 or 1.1 with this SQLObject version and Python 2.4 / 2.5. I haven't tested with Python 2.3 though.