Martijn, Jim, Ann et al

> -----Original Message-----
> 1) a server configurable option?

Yes, this could represent the maximum amount of time allowed per qry
(select/update/delete/add index etc etc) or a value of 0 for unlimited. The
default could be 0 for backward compatibility.

> 2) a database configurable option?

Personally I would not like this, it doesn't seem flexible enough, that
being said a user level time out set by SYSDBA/owner might be nice,
especially in future versions if the users table becomes part of the
database.

> 3) a connection configurable option?

Would seem the simplest, specify timeout=nn in conn string, if not present
default to 0 (unlimited) or capped to server max time out value.

> 4) all of the above?

Why not :-)

> Is a timeout elapsed time or cpu time? Elapsed time is
> problematic on a heavily loaded system since delay can be
> induced by other requests either hogging the system or
> holding a blocking resource.

Personally I would go for elapsed time, however I'm not developing the
solution so it might be totally impracticable.

> Killing a valid request seems
> more than a little unfair, but killing a valid request in a
> heavy loaded system that is going to automatically restart is
> a guarantee of livelock.

It shouldn't be unfair, the SYSDBA is ultimately responsible for specifying
the max time-out period (if any) for a server. If this time-out period is
broken it could indicate a problem with time-out being too low or queries
etc which are not optimized enough, either way it should be a policy
decision by companies/sysdba's on what the time-out limit is if set.

> If on the database, how do you be sure that we don't fall
> into the Hitch-hikers Guide trap and kill the query that's 2 seconds from

giving us the ultimate question to the

> ultimate answer?

Probably by not specifying a time-out value at all for both the server or
connection. I fully agree there are going to be systems that are not going
to require/want this feature at all.

> But all in all I feel that a way to identify and kill a particular request

would cover

> all this and more, so why settle for less?

Would this not involve tracking [on the server] what client processes are
running by application/workstation/db user? Which imo would be really neat.
One of the things I like about SQL Server is the ability to see what user is
connected to the server using what client application (pretty sure you can
see client app in SQL Server but could be wrong).

> I agree. A way for the client to terminate a query would be very nice. I

fear that a system wide timeout in many > cases would cause more frustration
that it solves. Connection wide and statement wide timeouts would be OK as

> long as the default is infinitive.

To me the system wide time-out is more of a failsafe, if you as a DBA don't
want a thread to potentially run for ever then you could, if required,
specify a value which is the maximum time-out, regardless of what other
time-out values are. I fully agree that the default should be infinitive
and the solution should be one that needs to be turned on if required.

Rgds

Si Carter
http://www.fbtalk.net/
http://www.tectsoft.net/