Re: [SQLObject] Bug? Spurious connection to postgresql

[Oleg B. <ph...@ph...>]

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/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.