|Subject||Re: [Firebird-Architect] Can we, can we, can we????...|
> > >This means that the real need is for elapsed time, not number ofExactly - I kinda said that as well.
> > >reads/fetches, not CPU time.
> > >
> > The state purpose of the request was to catch "bad" requests, not
> > from bored users. Maybe we're talking about one thing here, maybe
> I believe we are talking about the same thing.
> By mentioning users, I did not immediately mean that they are/were
> 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
> > 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
> 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.
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
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL