Обсуждение: Re: idea to have driver return immediately after a query

> 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

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

Dave Cramer <pg@fastcrypt.com> wrote:

> 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.

It doesn't solve it for all cases, but it would make the default
behavior for many common usages more efficient.  FWIW, it would
match the behavior of the Sybase and MS SQL Server JDBC drivers, at
least last I used them.

As I said earlier in the thread, I think we may need a new protocol
version to have a really nice implementation which completely solves
the problem.  People are talking about that anyway, for a variety of
reasons, so we should make sure that if that effort moves forward
the new protocol can gracefully handle this case along with solving
the other problems people want to address.

-Kevin