On 28 March 2011 02:42, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
> Oliver Jowett wrote:
>> I'm a little worried about error handling too.
>
> Any code written for portability would deal with it, since most
> drivers stream the results and can throw exceptions on next(). (It
> is declared to throw that in the interface, after all.)
Sure, we do that too already when a fetchsize is set.
I was more worried about problems similar to this:
ResultSet rs1 = statement1.executeQuery();
// send Parse, Bind, Execute
// process parse, bind responses (all OK)
// return control to the caller
ResultSet rs2 = statement2.executeQuery();
// need to read statement1's pending results first
// oops - actually, statement1's query deadlocked, how do we
report that error sensibly?
If we don't ensure that the connection is in an idle state when we
return control to the caller, it's going to be hard to report errors
in the right context.
Oliver
