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

Don Dwiggins ddwiggins at advpubtech.com
Thu Nov 20 12:44:30 MST 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