Subject | Re: [Firebird-Architect] Can we, can we, can we????... |
---|---|
Author | Jim Starkey |
Post date | 2005-06-13T18:01:02Z |
Nando Dessena wrote:
heavily loaded system since delay can be induced by other requests
either hogging the system or holding a blocking resource. Killing a
valid request seems more than a little unfair, but killing a valid
request in a heavy loaded system that is going to automatically restart
is a guarantee of livelock. CPU might be better, but it appears that
pthreads doesn't provide any mechanism to get per thread CPU numbers, so
I'm afraid we're going to have to write that off.
How about limiting the number of fetches? We already track that, so a
limit would be computationally cheap. Numbers ecords read is another
possibility, but it would have to be records fetched rather than records
returned. Number of update operations, maybe?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>It looks like the only option that's flexible enough is having theIs a timeout elapsed time or cpu time? Elapsed time is problematic on a
>ability to set a database- or connection-wide optional timeout, and
>also the ability to set one (or disable the default one) at statement
>prepare time.
>
>
>
heavily loaded system since delay can be induced by other requests
either hogging the system or holding a blocking resource. Killing a
valid request seems more than a little unfair, but killing a valid
request in a heavy loaded system that is going to automatically restart
is a guarantee of livelock. CPU might be better, but it appears that
pthreads doesn't provide any mechanism to get per thread CPU numbers, so
I'm afraid we're going to have to write that off.
How about limiting the number of fetches? We already track that, so a
limit would be computationally cheap. Numbers ecords read is another
possibility, but it would have to be records fetched rather than records
returned. Number of update operations, maybe?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376