Ann W. Harrison wrote:

>Martijn Tonies wrote:
>
>
>>Because it doesn't make sense... See my web-server example.
>>
>>
>>
>
>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.

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.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376