Thread: 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