Welcome to the world of wan programming. It *can* be done, but you have to do it carefully. I think the problem you are running into, is that the ODBC driver might not have a 'timeout' setting enabled. I know that when I wrote a comm layer using a database and a jdbc driver, executing a 'select' would not timeout, even if the tcp connection was broken. I had to manually specify (in jdbc's dsn string) two timeout values, one for the connect, and one for the time that it took for the connection to return results. Additionally, even when the client timed out right and disconnected the connection, the *server* still thought it had a connection. This was a problem because we quickly reached a 'connection limit' for the server. So, I set the timeout for the jdbc connection && the database connection to the same value, and that (seemed) to work ok....

If you want to test this in the future, consider setting up an openbsd / freebsd box with ipfw on it. You can throttle the network connection, introduce random packet drops, etc. You can then automate your testing by using Net::Telnet or Net::SSH to send commands to ipfw, and Cluster::Run (not yet released, working on it at home) or your favourite Distributed:: module to stress test the server.

Good luck! Must get java filth off my hands... unclean! unclean!