Nickolay Samofatov wrote in fb-devel:

>
> Firebird 1.0 and earler versions handled internal page-level deadlocks
> internally in a very interesting way. In case of internal deadlocks it
> stopped _ALL_ contented processes for 10 seconds (DeadlockTimeout
> paremeter value) and then retried several times (possibly waiting
> again) before reporting internal deadlock to client. This caused
> server to collapse under load. For Firebird 1.0 this looked like
> this: under heavy load engine may enter state when clients have
> response time about 10-20 seconds for every query and server CPU's
> are not loaded at all.
>
> In Firebird 1.5 I changed the behaviour to report all deadlocks
> (including internal ones) instantly, without any timeouts.
> This change allows to use firebird under constant heavy load and have
> a predictable response time.

Nickolay, can you tell me when was this issue discussed before being
changed? I decided to promote the discussion here because it seems an
architecture decision, not a simple code change. And I only became fully
aware of the change when an app developer reported a new behavior, even if I
read all the changes to the CVS.

This is a low level behavior that -good or bad- has been for years and
changing it should fit the needs of most people, not only one developer.

- Is your reasoning/solution valid for all environments? Or only in the case
of several clients smashing the engine with quick and brief requests?
- Do all kinds of application get a benefit by being informed of ALL
deadlocks, as you wrote?
- What's the performance penalty for scanning immediately for deadlocks
instead of waiting some seconds like it was before?
- What are the internal deadlocks that are now passed to the application?
Isn't this overkill? Most deadlocks may be resolved quickly with an internal
"let's retry" instead of bothering the poor application.

Should this behavior be configurable instead?

Thanks in advance for your explanations.

C.
--
Claudio Valderrama C.
Consultant, SW developer.
www.cvalde.com - www.firebirdSql.org