Document a long standing problem in SO and bug SO maintainer to fix it

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 II. 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:

http://sourceforge.net/tracker/index.php?func=detail&aid=1407684&group_id=74338&atid=540674

I've tried recreating his problem, but was never able to.

The Solution

The file is declarative.py and the problem exists with the threadSafeMethod.

If you want the quick fix, comment out this line in declarative.py:

cls.__init__ = threadSafeMethod(lock)(cls.__init__)

We've been running a modified version of sqlobject for months in production with no problems.

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?

This problem was fixed in SQLObject 0.10.1.

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.

Ok to bump SO version. You asked on the ML and no one yelled.

Fixed in r5386.