Hi Rick, Thanks for your interest, I'll try to clarify.
> I'm interested in why you have chosen this workaround. If Derby's > interrupt handling is working correctly, then the database and all other > connections to it should be fine. Probably the interrupted connection is > fine too and you have only lost the transaction which was running in the > interrupted connection. Of course, Derby may not be performing the way > we think it should be. Could you explain why you chose this expensive > solution? In previous incarnations of the application, it would simply try to recreate the connection but even though it would receive a Connection object, every JDBC call would fail with the same exception. The solution I describe above was implemented when the application was using 10.4. It's certainly not lightweight but seemed to be the only sure approach. My hope is that if I can force the condition to arise, then I will be in a position to come up with error handling that works. If there are more lightweight solutions than that described above, then even better as long as I can prove to myself that what I've done actually works. > > Please bear with me, I do not understand the following paragraph: > > At the moment, this doesn't address the problem. Specifically, even > > after taking these steps, the exception gets thrown after every database > > operation. > When I read that sentence, I get the impression that the 08000 exception > is being thrown on every JDBC call. Is that right? Yes, that's correct. The issue is that I cannot force the 08000 condition but once it occurs, every JDBC call subsequent to that fails until the application is restarted. Note that I've never experienced any data corruption due to this, just problems with the connection; restarting the application has always resolved it. There's every possibility that there is a problem with the application code; it's certainly a little more convoluted that it should be and I'm trying to reduce the complexity bit by bit. For the moment though, my issue is not with the 08000 error per se, it's that I have no way to verify that the error handling that is invoked in response to the 08000 actually works. Thanks, Phil
