Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.

Shreyas Kaushik wrote:
> Please see below for my replies.
> 
> ~ Shreyas
> 
> Daniel John Debrunner wrote:

>> I think a detailed explanation of what you believe cancel and
>> setQueryTimeout functionality should be would be very useful. I'm not
>> sure closing the activation actually results in the expected behaviour.
>>  
>>
> setQueryTimeout  should go set the time until which a Query can execute
> after the executeQuery
> is called. In other words it specifies what is the upper limit for me to
> fetch the data.

Can you explain your reasoning behind this. The only guidance I see is
from the javadoc which does not mention anything about the application.
Maybe it is explained more in the tutorial book?

>From javadoc 1.4.2

public void setQueryTimeout(int seconds)
                     throws SQLException

Sets the number of seconds the driver will wait for a Statement object
to execute to the given number of seconds. If the limit is exceeded, an
SQLException is thrown.


> Regarding the cancel() it is same as what JDBC spec says. One thread
> should be able to cancel the execution
> of a statement from another thread. When query times or otherwise a call
> to cancel() should stop the execution
> of a statement and clear up all resources.

Having cancel() call System.exit() would fulfill your description of the
functionality, but would probably not be what people would expect. :-)

How does a cancel affect the thread that is executing the statement,
what is the affect on the state of the database, connection or
transaction, statement, jdbc objects etc? What happens if the statement
isn't executing, or has a result set open but is not active in Derby?
These are the issues that need to be thought about and written down.

My guess is that the people who have been active on this discussion may
each have a slightly different (or completely different) idea of what a
cancel does, given it is not completely defined by the JDBC spec. Anyone
looking at your patch cannot begin to review it until they understand
what *detailed* functionality you believe your are implementing. Then
there may be discussions on is it the required functionality, and does
the patch actually implement the intended functionality.


Dan.