Subject Re: [Firebird-Architect] Can we, can we, can we????...
Author Martijn Tonies
> > >This means that the real need is for elapsed time, not number of
> > >reads/fetches, not CPU time.
> > >
> > The state purpose of the request was to catch "bad" requests, not
> relief
> > from bored users. Maybe we're talking about one thing here, maybe
> two.
> I believe we are talking about the same thing.
> By mentioning users, I did not immediately mean that they are/were
> bored.
> I was referring to the need to be able to assure my users (actually
> their boses) that the database will not allow for a request to 'runaway'
> and consume server resources without end.
> > As mentioned, the problem with bored users killing long requests is
> that
> > they invariably restart them, wasting all of the resources expended so
> > far.
> I agree!
> > ...isn't the better solution a SQL analog of the isc_unwind_request
> call?
> Yes.
> But I believe you will agree, the ability to cancel a query and a
> feature which allows for the SYSDBA / Application developer to control
> the runtime of a query are not mutually exclusive.
> They are complimentary.

Exactly - I kinda said that as well.

I agree with Sean. Elapsed time is the only thing that users care about.

A per-statement or per-connection defined timeout makes sense.

A per-database configured timeout makes sense as well (think

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Upscene Productions