db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Date Tue, 01 Mar 2005 10:33:56 GMT
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.
>
>
>
>  
>

Mime
View raw message