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 Mon, 07 Mar 2005 08:04:50 GMT
~ I looked at the possible usage of java.util.Timer and java.util.TimerTask.
  Although it may seem to be a correct approach to use them at the first
  thought it has some practical drwbacks to its usage in this scneario.
                                                                                         
                                   

~ At a time there is a only *one* Timer per system running( as earlier
discussions in this list have suggested ). If that is the case a call to the
statement's setQueryTimeout() method will a create TimerTask that is
responsible for timing out of that statement and may be a subsequent cancel
when the timeout happens.
                                                                                         
                                   

~ Now when one statement's timeout mechanism is at work on the Timer thread,
other statements have timeout's set on them they'll have to wait until the
current task is completed( eventhough others are scheduled for immediate
execution on the Timer). I tested this behaviour by writing a program that
schedules multiple tasks on the Timer for immediate execution.
                                                                                         
                                   

~ If the current statement that is occupying the Timer times out and calls a
cancel() and the cancel takes a while to return ( this could be because of
various reasons), statements will queue up waiting for the Timer.
                                                                                         
                                   

~ Using the Timer and TimerTask may have just one thread, but the above
mentioned drawback could be a major performance hit causing more latency in
statement execution.

To summarize with using the Timer and TimerTask we'll basically use a 
single-threaded approach as there will be one centralized timer.So I 
guess we need to work a solution to get this through. We may consider 
using the solution I proposed.
                                                                                         
                                  

And also pointers on what all should happen during cancel() will be helpful.
As different people may see the cancel behaviour differently as Dan 
mentioned
in one of his mails.

~ Shreyas


Daniel John Debrunner wrote:

>Shreyas Kaushik (JIRA) wrote:
>
>  
>
>>     [ http://issues.apache.org/jira/browse/DERBY-31?page=history ]
>>
>>Shreyas Kaushik updated DERBY-31:
>>---------------------------------
>>
>>    Attachment: Derby-31.patch
>>
>>This is the patch for implementing setQueryTimeout() in  EmbedStatement.java . I clsoe
the activation for the statement when the query times out so that the query stops executing.
I tested this by inserting data into a table continuosly for about 12 hours and then doing
a select * on it by setting the time out to 1 sec. It worked fine by cancelling the statement
execution when the timeout happened.
>>
>>    
>>
>
>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.
>
>I also think the timing should be centralized per database or per
>system, using java.util.Timer and TimerTask. With your implementation a
>Thread per statement will be created when using query timeouts. Creating
>threads is expensive in Java and there was a request against Cloudscape
>to create one background thread per system, rather than the current case
>of one per database. This is to handle the situation where there are
>hundreds or thousands of databases per system.
>
>Dan.
>
>  
>


Mime
View raw message