Subject | Re: [Firebird-Architect] FW: Deadlocks on FB1.5 |
---|---|
Author | Jim Starkey |
Post date | 2003-05-14T14:41:37Z |
At 04:17 AM 5/14/03 -0400, Claudio Valderrama C. wrote:
In most cases, delivery of a blocking AST will cause a lock to be downgraded,
clearing the deadlock. But for this to happen, the process holding the lock
must receive and process the AST. In a heavily loaded system any number
of things can delay the process. And since the physical access paths are
"known" to be deadlock free, there is no code to recover from transient
deadlocks.
Superserver is a different animal. But how different is restrained by an
unnatural
common code base with classic.
Jim Starkey
>Nickolay Samofatov wrote in fb-devel:The problem here is that in classic, not all deadlocks are actually deadlocks.
> >
> >
> > 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.
In most cases, delivery of a blocking AST will cause a lock to be downgraded,
clearing the deadlock. But for this to happen, the process holding the lock
must receive and process the AST. In a heavily loaded system any number
of things can delay the process. And since the physical access paths are
"known" to be deadlock free, there is no code to recover from transient
deadlocks.
Superserver is a different animal. But how different is restrained by an
unnatural
common code base with classic.
Jim Starkey