Please see below for my replies.
~ Shreyas
Daniel John Debrunner wrote:
setQueryTimeout should go set the time until which a Query can execute after the executeQueryShreyas 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.
is called. In other words it specifies what is the upper limit for me to fetch the data.
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.
I also think the timing should be centralized per database or perOk creating threads are costly, but the time out is set per query , if there are multiple queries excuting
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.
at the same time with different time out's how should this be handled?
Dan.
