> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of
> Martijn Tonies
> Sent: 14. juni 2005 21:06
> To: Firebird-Architect@yahoogroups.com
> Subject: Re: [Firebird-Architect] Can we, can we, can we????...
>
> > > 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?
>
> We both agree that a "end of month" query should be able to
> run just fine, despite a busy server or whatever else...
>
> My example was this:
> Imagine a ISAPI application that processes queries to a
> Firebird database.
> These queries will run endlessly (no timeout). Some of the
> queries are somewhat "heavy".
>
> Connections are pooled in the ISAPI dll.
>
> A user asks for a webpage with a heavy query. But the server
> is busy and is slowish.
>
> Here's what happens:
> - user asks for page
> - ISAPI dll will take a connection from the pool and process query
> - query runs...
>
> - user gets annoyed and uses "Refresh" button
> - ISAPI dll will take a connection from the pool and process query
> - query runs...
>
> If there was a timeout, the ISAPI dll could respond with a
> "busy" page instead and let the user know what's going on.
> Obviously, a "cancel"
> button doesn't work here.

In this specific case it would then be nice to be able to specify a timeout
value for that specific statement. Not as a general server wide or database
wide time out.

As far as I can understand this thread are discussing three different
things.

1) The ability to terminate your own statements from the client application.
2) The ability for the server to terminate runaway queries. What is
interesting with this is how the server knows that it is a runaway query or
not just a long running query....
3) The ability for the client application to specify a timeout value for
each query. As in the web-server example.


/smn