Subject | Re: [Firebird-Architect] Can we, can we, can we????... |
---|---|
Author | Alexandre Benson Smith |
Post date | 2005-06-14T19:41:57Z |
Ann W. Harrison wrote:
What I understand from the posts is:
1.) A way to cancel a running query (as suggested by Jim)
2.) A way to automatically cancel a query (as requested ealier)
Jim said that the option 1 is easy to implement, and will be good for
everyone
The option 2 seems to have some aspects to be defined
1.) How to measure the "time/resource" [a) time (elapsed/cpu/time in
looper) b) page fetches] to know if an application is running for a long
time
2.) How to define this measure a) database wide, b) connection wide, c)
per statement
I will tell what I think is good, maybe I am just overlooking, maybe
don't see the negative aspects, or technical inviablility.
The option 1 are agreed by everyone to be a good thing
The option 2 is IMHO good too, since one could define an upper limit for
general propouse
When one needs a legitimate long running query the conection parameter
could be used, so the month-end reports don't stop to work, the same
conection parameter could be used for gbak too.
The ideal measure unit is time, again IMHO, I'd like to say, stop every
query that runs for more than 5 minutes, if I wish it I could override
it by the connection string or even better with an SQL statement (Set
Timeout to 15 minutes, set timeout to 0 minutes --unlimited).
As far discussed, there is no way to get the CPU time, and I agree that
elapsed time will be a more friendly way to define it from the user POV,
on the other way the fetch count will be free, since it is already done
internally, as Dmitry said calculate the elapsed time will not hurt
either (at least from initial analyses).
My question:
Is possible to define the timeout on the fly ? (maybe using some "SQL"
command)
If so, the DBA could determine a general timeout, and the developer
could embed specifc timeout for special statements (longer or shorter)
as needed and the developer could provide a stop button for the user
when he wants to stop anything.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.2 - Release Date: 14/06/2005
>I guess I don't understand your web-server example. What I thought IPeople,
>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?
>
>Cheers,
>
>
>Ann
>
>
What I understand from the posts is:
1.) A way to cancel a running query (as suggested by Jim)
2.) A way to automatically cancel a query (as requested ealier)
Jim said that the option 1 is easy to implement, and will be good for
everyone
The option 2 seems to have some aspects to be defined
1.) How to measure the "time/resource" [a) time (elapsed/cpu/time in
looper) b) page fetches] to know if an application is running for a long
time
2.) How to define this measure a) database wide, b) connection wide, c)
per statement
I will tell what I think is good, maybe I am just overlooking, maybe
don't see the negative aspects, or technical inviablility.
The option 1 are agreed by everyone to be a good thing
The option 2 is IMHO good too, since one could define an upper limit for
general propouse
When one needs a legitimate long running query the conection parameter
could be used, so the month-end reports don't stop to work, the same
conection parameter could be used for gbak too.
The ideal measure unit is time, again IMHO, I'd like to say, stop every
query that runs for more than 5 minutes, if I wish it I could override
it by the connection string or even better with an SQL statement (Set
Timeout to 15 minutes, set timeout to 0 minutes --unlimited).
As far discussed, there is no way to get the CPU time, and I agree that
elapsed time will be a more friendly way to define it from the user POV,
on the other way the fetch count will be free, since it is already done
internally, as Dmitry said calculate the elapsed time will not hurt
either (at least from initial analyses).
My question:
Is possible to define the timeout on the fly ? (maybe using some "SQL"
command)
If so, the DBA could determine a general timeout, and the developer
could embed specifc timeout for special statements (longer or shorter)
as needed and the developer could provide a stop button for the user
when he wants to stop anything.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.2 - Release Date: 14/06/2005