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@debian.org INIT.D Developer fog@initd.org I terminali seriali sono in via di estinzione (infatti quello che c'era si è estinto) -- Simone Caldana