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

[Shreyas Kaushik]

Please see below for my answers
~ Shreyas
Daniel John Debrunner wrote:
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.
 

My reasoning was, when the time out set has expired the statement object 
should stop
executing whatever it is doing. I used the term "executeQuery" in one of 
my previous
replies was becuase in my current patch I had covered this time out for 
executeQuery().

 

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.
 

What would be a good starting point to do this ? Some pointers here 
would help.

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.
 

Ok agreed. Once we reach a concenses on the topics that you have talked 
about
above a patch can be circulated here and driven to conclusion.

Dan.