Subject | Re[4]: [Firebird-Architect] FW: Deadlocks on FB1.5 |
---|---|
Author | Nickolay Samofatov |
Post date | 2003-05-15T10:16:05Z |
Hello, Claudio,
retry-wait loop very responsive under contention (lock ownership
switch delay is several ns on Linux, ~40 ms on windows as compared
to several seconds or total lock-up on Windows XP earlier).
> Nickolay Samofatov wrote:I'm testing more simple and elegant solution now. It seems it makes
>> 3. DPM/VIO code has a lot of places where deadlocks are possible.
>> Many places in DPM rely on fixed 1 second timeouts to detect and
>> process deadlocks. The problem is that deadlocks are now getting
>> reported before 1 second timeout and page locking retry loop is
>> looping too quickly. If I add manual 1-second timeout in those loops
>> everything will work as it worked before.
> But I assume this is only a temporary fix while v1.5 is released, while you
> rework more code, right?
retry-wait loop very responsive under contention (lock ownership
switch delay is several ns on Linux, ~40 ms on windows as compared
to several seconds or total lock-up on Windows XP earlier).
>> 4. There is a bug that if locking problem happens duringIt is safe alternative to doing BUGCHECK in this case.
>> transaction-level savepoint backout during rollback engine reports
>> BUGCHECK(290) instead of declaring transaction as DEAD and continue
>> working.
> Mark it as dead? Is it safe or is it the only alternative?
> If tpb_no_auto_undo is used, you'll never encounter such case, I guess, sinceTrue.
> there's no list of actions to undo, hence the actions inside the txn can't
> be undone to mark it as committed.
> BTW, what happens if tpb_no_auto_undo is specified at txn start time andExplicit savepoints are granted and work as expected.
> explicit requests for savepoints are made: some strange condition or the
> explicit savepoints are granted and work as expected?
> Claudio Valderrama C.Nickolay Samofatov