db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oyvind Bakksjo (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Date Mon, 13 Jun 2005 09:32:47 GMT
    [ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12313431 ] 

Oyvind Bakksjo commented on DERBY-31:
-------------------------------------

Hi Dan, thanks for reviewing this patch so quickly.

I am fully aware of and share you concern for the performance impact of creating all the TimerTask
objects. It is far from ideal. The problem is that the Timer class _forces_ recreation of
TimerTask objects, since these can't be reused; when a TimerTask has run or been cancelled,
it is pure waste. Trying to schedule the same task again will cause an exception. If it wasn't
for this, we could associate a TimerTask with each StatementContext object.

This performance impact will, however, only affect queries with a timeout value set. As such,
it is a tradeoff - you can get timeouts, but that will slow down your execution.

If it turns out that the calls to checkCancellationFlag() seriously affect performance, these
calls could be decimated by doing the call only for each n-th row. (It sure will be nice to
get that performance regression test, so we'll see the actual impact.) For the time being,
I can do some rudimentary testing of this myself.

I agree a separate module for the timer might be overkill. As for the interface, my idea was
that more methods than getCancellationTimer() could be added as needs arose for Timers for
other purposes. It would be up to the implementing class whether to actually return the same
Timer object. I guess it would depend on the duration of the TimerTasks and the responsiveness
requirements whether to use multiple Timers or just a single one.

I meant to support milliseconds use internally and seconds at the JDBC API level. I guess
it would be more consistent if I used milliseconds in the language PreparedStatement interface
as well. And yes, I'll fix throwing an exception on negative timeout values.

> Statement.setQueryTimeout() support.
> ------------------------------------
>
>          Key: DERBY-31
>          URL: http://issues.apache.org/jira/browse/DERBY-31
>      Project: Derby
>         Type: New Feature
>   Components: JDBC
>  Environment: ALL
>     Reporter: Ali Demir
>     Assignee: Oyvind Bakksjo
>  Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status
>
> Calling Statement.setQueryTimeout() throws exception saying that function is not supported.
This is an important JDBC feature and is limiting our options to use Derby with our JDBC code.
Implementing this JDBC function would make Derby much easier to adopt.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message