[Twisted-Python] Re: Exception handling in t.e.adbapi

Don Dwiggins ddwiggins at advpubtech.com
Thu Nov 20 14:44:30 EST 2008

Jean-Paul, thanks for the reply:
  > How do you tell the difference between a network error which prevented a
> statement from being executed by the SQL server and a network error which
> only prevented the response indicating that the statement was successfully
> executed from being returned to you?  If you can't tell the difference, how
> do you ensure that you don't re-execute statements which modify the 
> database causing corruption of your data?

Well, I was a bit cryptic in my description.  Based on experience with 
SQL Server and experimentation with different conditions, I'm pretty 
sure I can tell from the exception data whether the statement completed 
successfully.  You're right, though, I do need to be careful about this.

> I've never used pyodbc, but presumably the exception indicates you're
> using the objects in a thread where they're not allowed to be used.

By tracing through the operation of adbapi, I figured out why I was 
getting that message when the network is down:  Connection.reconnect 
does a ConnectionPool.disconnect followed by a ConnectionPool.connect, 
which does a dbapi.connect; this fails, since the network is still down. 
  The exception is caught in _runInteraction, which tries to do a 
conn.rollback, which calls ConnectionPool.disconnect.  Since there's no 
connection at this point, I get the "wrong connection" exception.

The moral of the story seems to be that I need to rethink how to detect 
the difference between a "stale" connection with the network back up, 
and a network down condition.  Another possibility would be to adapt 
adbapi to work in one-connection-per-operation mode, so there'd never be 
an open connection hanging around.  (This sort of defeats the point of 
ConnectionPool, but the API of the module would be preserved.)

Don Dwiggins
Advanced Publishing Technology

More information about the Twisted-Python mailing list