[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