[Twisted-Python] twisted.enterprise.adbapi and connection pool problem

Federico Di Gregorio fog at initd.org
Tue Feb 15 10:54:54 EST 2005


Il giorno mar, 15-02-2005 alle 10:35 -0500, James Y Knight ha scritto:
> On Feb 15, 2005, at 4:22 AM, Federico Di Gregorio wrote:
> > If the database support transactions and an exception is raised the
> > DatabasePool does a .rollback() (if I remember correctly). In this case
> > you're sure the query has not been executed (it was rolled back
> > explicitly.)
> 
> If the database server returned an exception and you can actually 
> execute a rollback, the connection didn't die. :) That is not the 
> situation we're talking about. It's when you send a command over the 
> network, and the remote host maybe gets it, or maybe not, and then you 
> unplug your net connection before you get a response. You don't know if 
> the server got the command or not. However, your point stands: If 
> you're in a transaction and failed anything but the commit, then you 
> know the transaction was unexecuted. If you fail the commit command, 
> it's harder. With certain errors you know came from the database server 
> rather than the network, you can probably also know it's unexecuted, 
> but in some cases it's unclear.

Agreed. If you fail (probably because of network problems) during the
commit the situation can be so bad that shutting down the application
until you can check the database is a very good idea. :/

> In contrast to my previous message, I do believe cp_reconnect will 
> notice a failed connection before attempting a query on it, since it 
> checks the result of db.cursor() when starting the transaction, and if

It depends on the database adapter. For example, in psycopg, you can
call conn.cursor() on an "unplugged" connection without getting any
errors. It is the curs.execute() that will fail. Sending data to the
backend at every .cursor() just to check the connection status is an
overhead that some people don't want.

> that fails, reconnects. This is likely sufficient for most website-like 
> application, where a failed query just results in the user pressing 
> reload anyways.
> 
> For a more serious application, it should handle any errors sensibly, 
> including those that happen at commit time, so it needs to be able to 
> handle errors itself, in any case.

I agree but I don't see any sensible way to manage an error at .commit()
time.

federico

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog at debian.org
INIT.D Developer                                           fog at initd.org
  I terminali seriali sono in via di estinzione (infatti quello che
   c'era si è estinto)                                 -- Simone Caldana
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20050215/2747ed68/attachment.pgp 


More information about the Twisted-Python mailing list