Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#163 destroySelf in transaction causes lockup

closed-fixed
Oleg Broytman
None
5
2006-04-06
2006-03-26
Cody Pisto
No

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

Discussion

  • Cody Pisto
    Cody Pisto
    2006-03-26

    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@lists.sourceforge.net/msg00226.html

    After contacting the poster, reverting to a much older
    version of sqlobject (r1547) seems to work around the issue

     
  • Cody Pisto
    Cody Pisto
    2006-03-26

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

     
  • Cody Pisto
    Cody Pisto
    2006-03-26

    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.

     
  • Cody Pisto
    Cody Pisto
    2006-03-26

    Patch to solve problem

     
    Attachments
  • Oleg Broytman
    Oleg Broytman
    2006-04-06

    • assigned_to: nobody --> phd
    • status: open --> closed-fixed
     
  • Oleg Broytman
    Oleg Broytman
    2006-04-06

    Logged In: YES
    user_id=4799

    Fixed by the patch N 1464379.