db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: DERBY-31: setQueryTimeout semantics
Date Thu, 21 Apr 2005 15:55:49 GMT
Oyvind.Bakksjo@Sun.COM wrote:

> In order to come up with a design and an implementation for
> Statement.setQueryTimeout() and Statement.cancel(), we need to agree on
> the semantics.

<good semantics for cancel/timeout snipped>


> Other ideas:
> * The tradeoff between cancellation responsiveness and performance
> degradation could be made configurable with a property set by the user.

I would be against this tuning property. One of the ways to make an easy
to use database is to start with the mindset that no tuning properties
should be allowed and work from that, rather than defering the problem
to the user by making them select a value for a property. One of the
issues with such a property is that unless you provide clear guidelines
on when/how to set it, then really it becomes more of a time waste than
a useful feature.

I believe that Derby already has too many tuning properties and would
like to see it move towards a single tuning property, such "how much
memory can this database use". Everything else would be self tuned.

Properties that affect the functional behaviour of Derby I do not count
as being tuning properties, ones such as security setup.

> ----------
> (*) It is possible to write long-running statements which a certain
> database implementation, in theory, can defer execution of, until the
> application calls ResultSet.next(). In such a case, the execute phase
> will be quick, but fetching a single record may take longer time than
> the query timeout that was set for the statement. In practice, this will
> rarely be the case. If it should prove to be a problem later, one could
> consider applying the query timeout to the execution of
> ResultSet.next(), but for now I don't think we should worry about it.

I actually think that next() (or any ResultSet method that moves to a
row) taking a long time is not rare, it will be just (or almost) as
common as executeQuery taking a long time. A typical case would be the
locks for the rows required by the next are held by other transactions
and therefore the next() has to wait. Or with a complex join the amount
of work to determine the first row may be almost identical to that to
determine the Nth row.

Dan.



Mime
View raw message