You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Oy...@Sun.COM on 2005/05/26 15:00:40 UTC
DERBY-31: More on semantics for Statement.setQueryTimeout:
ResultSet.updateRow
Previously, we agreed that the query timeout should apply to
Statement.execute() as well as each individual call to ResultSet.next().
New question: Should the query timeout apply to ResultSet.updateRow() as
well. For orthogonality, the question (although this is more of
theoretical interest) also applies to ResultSet.deleteRow()?
My initial gut feeling is that it should not; even though updating e.g.
a large blob may take a while, I still think timing out on an operation
like this would be more annoying than useful to the user.
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: DERBY-31: More on semantics for Statement.setQueryTimeout:
ResultSet.updateRow
Posted by "Lance J. Andersen" <La...@Sun.COM>.
The wording in the JDBC 4 spec is going to indicate that
setQueryTimeout must be in effect for executeXXX methods.
For ResultSet methods, this is optional as the driver vendors vary in
their support of this.
-lance
Daniel John Debrunner wrote:
>Lance J. Andersen wrote:
>
>
>
>>you are correct, timeouts are not documented to effect xxxRow()
>>specifically in the jdbc 3 or 4 spec
>>
>>
>
>Lance, I'm a little confused by your comment.
>
>Who do you think is correct, David or Oyvind? From my reading they have
>different gut feelings. :-)
>
>And then is it
>
>A) JDBC spec does not state anything about timeouts and
>updateRow/deleteRow/insertRow
>
>or
>
>B) JDBC spec states timeouts do not affect updateRow/deleteRow/insertRow
>(if so, which section?)
>
>
>???
>
>
>I think you mean A) but it's not entirely clear to me.
>
>Dan.
>
>
>
>>David Van Couvering wrote:
>>
>>
>>
>>>I'm guessing the JDBC spec doesn't have anything to say about this?
>>>
>>>Do we know what other drivers do for updateRow() and deleteRow()?
>>>
>>>Barring any existing explicit or implicit standard behavior, my
>>>feeling is that any method that results in a remote round-trip should
>>>support a timeout. I have dealt with too many applications where the
>>>application hangs if for some reason the remote service is not
>>>responding.
>>>
>>>Thanks,
>>>
>>>David
>>>
>>>Oyvind.Bakksjo@Sun.COM wrote:
>>>
>>>
>>>
>>>>Previously, we agreed that the query timeout should apply to
>>>>Statement.execute() as well as each individual call to ResultSet.next().
>>>>
>>>>New question: Should the query timeout apply to ResultSet.updateRow()
>>>>as well. For orthogonality, the question (although this is more of
>>>>theoretical interest) also applies to ResultSet.deleteRow()?
>>>>
>>>>My initial gut feeling is that it should not; even though updating
>>>>e.g. a large blob may take a while, I still think timing out on an
>>>>operation like this would be more annoying than useful to the user.
>>>>
>>>>
>>>>
>
>
>
>
Re: DERBY-31: More on semantics for Statement.setQueryTimeout:
ResultSet.updateRow
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Sorry if i was not clear, what is behind curtain 'A' was what i was
trying to state. :-)
I do not believe the intent in the current JDBC spec was for the timeout
to ever effect anything but the Statement.executeXXX methods.
I will have to raise this with the EG and clarify this in the 4.0
specification.
-lance
Daniel John Debrunner wrote:
>Lance J. Andersen wrote:
>
>
>
>>you are correct, timeouts are not documented to effect xxxRow()
>>specifically in the jdbc 3 or 4 spec
>>
>>
>
>Lance, I'm a little confused by your comment.
>
>Who do you think is correct, David or Oyvind? From my reading they have
>different gut feelings. :-)
>
>And then is it
>
>A) JDBC spec does not state anything about timeouts and
>updateRow/deleteRow/insertRow
>
>or
>
>B) JDBC spec states timeouts do not affect updateRow/deleteRow/insertRow
>(if so, which section?)
>
>
>???
>
>
>I think you mean A) but it's not entirely clear to me.
>
>Dan.
>
>
>
>>David Van Couvering wrote:
>>
>>
>>
>>>I'm guessing the JDBC spec doesn't have anything to say about this?
>>>
>>>Do we know what other drivers do for updateRow() and deleteRow()?
>>>
>>>Barring any existing explicit or implicit standard behavior, my
>>>feeling is that any method that results in a remote round-trip should
>>>support a timeout. I have dealt with too many applications where the
>>>application hangs if for some reason the remote service is not
>>>responding.
>>>
>>>Thanks,
>>>
>>>David
>>>
>>>Oyvind.Bakksjo@Sun.COM wrote:
>>>
>>>
>>>
>>>>Previously, we agreed that the query timeout should apply to
>>>>Statement.execute() as well as each individual call to ResultSet.next().
>>>>
>>>>New question: Should the query timeout apply to ResultSet.updateRow()
>>>>as well. For orthogonality, the question (although this is more of
>>>>theoretical interest) also applies to ResultSet.deleteRow()?
>>>>
>>>>My initial gut feeling is that it should not; even though updating
>>>>e.g. a large blob may take a while, I still think timing out on an
>>>>operation like this would be more annoying than useful to the user.
>>>>
>>>>
>>>>
>
>
>
>
Re: DERBY-31: More on semantics for Statement.setQueryTimeout: ResultSet.updateRow
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Lance J. Andersen wrote:
> you are correct, timeouts are not documented to effect xxxRow()
> specifically in the jdbc 3 or 4 spec
Lance, I'm a little confused by your comment.
Who do you think is correct, David or Oyvind? From my reading they have
different gut feelings. :-)
And then is it
A) JDBC spec does not state anything about timeouts and
updateRow/deleteRow/insertRow
or
B) JDBC spec states timeouts do not affect updateRow/deleteRow/insertRow
(if so, which section?)
???
I think you mean A) but it's not entirely clear to me.
Dan.
> David Van Couvering wrote:
>
>> I'm guessing the JDBC spec doesn't have anything to say about this?
>>
>> Do we know what other drivers do for updateRow() and deleteRow()?
>>
>> Barring any existing explicit or implicit standard behavior, my
>> feeling is that any method that results in a remote round-trip should
>> support a timeout. I have dealt with too many applications where the
>> application hangs if for some reason the remote service is not
>> responding.
>>
>> Thanks,
>>
>> David
>>
>> Oyvind.Bakksjo@Sun.COM wrote:
>>
>>> Previously, we agreed that the query timeout should apply to
>>> Statement.execute() as well as each individual call to ResultSet.next().
>>>
>>> New question: Should the query timeout apply to ResultSet.updateRow()
>>> as well. For orthogonality, the question (although this is more of
>>> theoretical interest) also applies to ResultSet.deleteRow()?
>>>
>>> My initial gut feeling is that it should not; even though updating
>>> e.g. a large blob may take a while, I still think timing out on an
>>> operation like this would be more annoying than useful to the user.
>>>
>>
>
Re: DERBY-31: More on semantics for Statement.setQueryTimeout:
ResultSet.updateRow
Posted by "Lance J. Andersen" <La...@Sun.COM>.
you are correct, timeouts are not documented to effect xxxRow()
specifically in the jdbc 3 or 4 spec
David Van Couvering wrote:
> I'm guessing the JDBC spec doesn't have anything to say about this?
>
> Do we know what other drivers do for updateRow() and deleteRow()?
>
> Barring any existing explicit or implicit standard behavior, my
> feeling is that any method that results in a remote round-trip should
> support a timeout. I have dealt with too many applications where the
> application hangs if for some reason the remote service is not
> responding.
>
> Thanks,
>
> David
>
> Oyvind.Bakksjo@Sun.COM wrote:
>
>> Previously, we agreed that the query timeout should apply to
>> Statement.execute() as well as each individual call to ResultSet.next().
>>
>> New question: Should the query timeout apply to ResultSet.updateRow()
>> as well. For orthogonality, the question (although this is more of
>> theoretical interest) also applies to ResultSet.deleteRow()?
>>
>> My initial gut feeling is that it should not; even though updating
>> e.g. a large blob may take a while, I still think timing out on an
>> operation like this would be more annoying than useful to the user.
>>
>
Re: DERBY-31: More on semantics for Statement.setQueryTimeout:
ResultSet.updateRow
Posted by David Van Couvering <da...@vancouvering.com>.
I'm guessing the JDBC spec doesn't have anything to say about this?
Do we know what other drivers do for updateRow() and deleteRow()?
Barring any existing explicit or implicit standard behavior, my feeling
is that any method that results in a remote round-trip should support a
timeout. I have dealt with too many applications where the application
hangs if for some reason the remote service is not responding.
Thanks,
David
Oyvind.Bakksjo@Sun.COM wrote:
> Previously, we agreed that the query timeout should apply to
> Statement.execute() as well as each individual call to ResultSet.next().
>
> New question: Should the query timeout apply to ResultSet.updateRow() as
> well. For orthogonality, the question (although this is more of
> theoretical interest) also applies to ResultSet.deleteRow()?
>
> My initial gut feeling is that it should not; even though updating e.g.
> a large blob may take a while, I still think timing out on an operation
> like this would be more annoying than useful to the user.
>
Re: DERBY-31: More on semantics for Statement.setQueryTimeout: ResultSet.updateRow
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
I agree. While it is possible for updateRow() and deleteRow() to take
sometime, this may not be very common.
Satheesh
Oyvind.Bakksjo@Sun.COM wrote:
> Previously, we agreed that the query timeout should apply to
> Statement.execute() as well as each individual call to ResultSet.next().
>
> New question: Should the query timeout apply to ResultSet.updateRow()
> as well. For orthogonality, the question (although this is more of
> theoretical interest) also applies to ResultSet.deleteRow()?
>
> My initial gut feeling is that it should not; even though updating
> e.g. a large blob may take a while, I still think timing out on an
> operation like this would be more annoying than useful to the user.
>