Subject | Re: [Firebird-Architect] Can we, can we, can we????... |
---|---|
Author | Martijn Tonies |
Post date | 2005-06-14T19:20:06Z |
Jim,
This is not at all always the case.
And yes, I agree there should be a way to kill a query from the same
client and/or connection that started the query in the first place.
IB7 has it :-)
With regards,
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
> >>Because it doesn't make sense... See my web-server example.You're assuming that there IS a system manager/dba available.
> >>
> >>
> >>
> >
> >I guess I don't understand your web-server example. What I thought I
> >understood is that you want the server to kill all requests when it gets
> >too busy, which may work in your case but makes a serious month-end
> >roll-up of accounts impossible. Surely in a web-server application, the
> >app itself could keep track of the elapsed time and use a kill request
> >call to slaughter its children?
> >
> >
> >
> Note:
>
> * Apache doesn't kill web requests that take too long
> * Microsoft Word doesn't kill Word documents that take too long open
> * Linux doesn't kill programs that take too long to run
> * Sambda doesn't kill file transfers that take too long to copy
>
> Servers are in the business of performing work for authorized clients.
> If the client gets bored waiting, the client should have a way to tell
> the server to give it up. A system manager or dba should be able to
> identify and kill runaway requests.
This is not at all always the case.
And yes, I agree there should be a way to kill a query from the same
client and/or connection that started the query in the first place.
IB7 has it :-)
With regards,
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
> Rather than go through the effort to put in a complex set of rules for
> stopping requests, why don't we spend the effort making it easy for a
> client to stop a request. For openers, we should make sure that a
> broken socket stops a request (since DSQL doesn't and a statement kill,
> I'm quite sure this isn't the case). Then lets make an architecturally
> supportable statement kill mechanism and an easy to use client library
> to expose the feature:
>
> void *timer = fb_start_reaper(statusVector, connectString, password,
> requestHandle, timeToLive);
> fb_cancel_reaper(timer);
>
> We'll have better application programs and a simpler, faster engine.