Bugs item #1458595, was opened at 2006-03-26 05:52
Message generated for change (Comment added) made by phd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: SQLObject from repository
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cody Pisto (cpisto)
>Assigned to: Oleg Broytmann (phd)
Summary: destroySelf in transaction causes lockup
Initial Comment:
Calling destroySelf() on an sqlobject acquired in the
same explicit transaction (using conn.transaction()...)
causes the entire python interpreter to lockup if the
sqlobject schema in question has any SQLRelatedJoin's
and the accompaying remove[JoinCol]() function is
called in the transaction before destroySelf().
PDB stepping seems to be of no use,
the interpreter locks up on line 306 of dbconnection.py
"return cursor.execute(query)"
The same sequence of calls works without problems
outside a transaction.
Version details:
Python 2.4.2
PostgreSQL 8.1.2 (via psycopg2 2.0b8 or psycopg 1.1.21)
SQLObject 0.8dev r1668 and r1615
----------------------------------------------------------------------
>Comment By: Oleg Broytmann (phd)
Date: 2006-04-06 18:41
Message:
Logged In: YES
user_id=4799
Fixed by the patch N 1464379.
----------------------------------------------------------------------
Comment By: Cody Pisto (cpisto)
Date: 2006-03-27 01:32
Message:
Logged In: YES
user_id=118227
OK, found the problem.
The _SO_delete method on the Transaction class had no way of
specifying which connection to use for the query, thus a new
one was being created.
the attached patch fixes that.
----------------------------------------------------------------------
Comment By: Cody Pisto (cpisto)
Date: 2006-03-27 01:14
Message:
Logged In: YES
user_id=118227
OK, after further investigation,
It seems that for some reason a second database connection
is being created during the lifetime of the transaction (by
one of the SQLObjects instantiated inside doInTransaction),
so a deadlock is occuring while this second connection waits
for a commit on the first connection, I am still investating
why this second connection is being created...
----------------------------------------------------------------------
Comment By: Cody Pisto (cpisto)
Date: 2006-03-26 08:27
Message:
Logged In: YES
user_id=118227
The following link seems to reference the exact same problem,
only on a slightly older version of sqlobject, and using mysql.
http://www.mail-archive.com/sqlobject-discuss@...>
After contacting the poster, reverting to a much older
version of sqlobject (r1547) seems to work around the issue
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338
|