Hello! I am going to work on this. If you are still interested I'd like to
have a discussion.
On Sat, Dec 13, 2008 at 07:26:14PM +0200, Iwan Vosloo wrote:
> When you call dropTable on a SQLObject class, _inside a transaction_,
> sqlobject creates a second connection to postgresql. This connection
> later deadlocks randomly with the first (which is sometimes busy inside
> a transaction).
>
> I can't figure out why the deadlock happens, but the second connection
> should never have been created to start with.
>
> If you run the code below, you'll see that createTable works correctly.
> This code does not illustrate the deadlock, only the extra connection.
>
> Using PDB, we've narrowed it to the following:
>
> In pgconnection.py, line:
> 163 if self.server_version[:3] <= "7.2":
>
> the attribute access to server_version results in a "poor mans
> aquisition" call to the method server_version on the Transaction's
> _dbConnection (a PostgresConnection).
>
> In there, on line:
> 304 server_version = self.queryOne("SELECT version()")[0]
>
> A query is executed on the underlying db connection.
>
> This is where the extra connection is created (the original is already
> in a transaction at this point).
I have never looked carefully into Transaction.__getattr__ and it seems
there is a number of clever tricks there. Too much to my taste but it's
impossible to fix it without big redesign.
The problem with .server_version is that it's a property, so it is
called at the very beginning of said __getattr__ and 'self' is the
Connection, not the Transaction so server_version calls wrong
self.queryOne(). I think, the simplest way to fix this would be to make the
property a normal method. Then __getattr__ will wrap self and the
.server_version() method will call .queryOne() on the Transaction, not
Connection.
This is an API change but I think it's a small evil 'cause it is a
change in an API that is hardly used by many.
What do you think?
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
