On Sun, Mar 27, 2011 at 12:46 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>> Oliver Jowett 03/27/11 9:10 AM >>>
>
>> 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?
>
> I guess we'd have to attach the SQLException object to the ResultSet
> and throw it the next time the ResultSet was accessed. We could
> debate about the fine points of whether there's a need to throw it if
> next() isn't called again; I can see arguments on both sides of that.
>
> [thinks some more]
>
> Although -- if there is a transaction-killing exception, that's
> something at the Connection level, so it would be proper to throw it
> on any and every attempt to use the connection before the transaction
> is reset, wouldn't it? Every ResultSet created within the context of
> that transaction should fail, shouldn't it?
>
> -Kevin
>
The problem here is that you can execute as many statements as you
want on a connection, so having all of the statements block on the
first statement or reading all of the first statements data doesn't
solve the problem since you could run out of memory reading the first
statements' data.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
