| Subject | Re: [firebird-support] "Page type 5 lock conversion denied" Error |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2008-04-08T17:47:08Z |
Greg Kay wrote:
which should have stopped all active processing.
Normal deadlock and lock conflict error occur when concurrent
transactions attempt to change the same record.
A lock conflict is detected while the record manager is finding
the appropriate version of the record for the running transaction
and realizes that 1) there is a newer version than this transaction
can see and 2) this transaction wants to change the record. In the
normal case, the second transaction waits for the first to finish
and if the first commits, the second gets an error.
A deadlock occurs when one transaction has run into a lock
conflict and is waiting and then the other transaction also runs
into a lock conflict and is about to wait. If there's a circular
wait - transaction A waiting for B which is waiting for C which
is waiting for D which is waiting for A, then there's a deadlock
and one of the participants gets an error.
However, what you're seeing is a failure in the page handling -
internally Firebird does non-transactional page locking. Locks
are taken and released furiously. For some reason, the data page
(type 5) number 708341 is being held by a thread that can't
release it and requested in an incompatible mode by the transaction
that got the error. This should NEVER happen.
Ann
>This is not a normal lock conflict error - it's an internal error
> We've just had a problem with a lock conflict in Firebird Classic
> 2.03. We got the error message
>
> Deadlock.
> Page 708341, page type 5 lock conversion denied.
>
> We had two batch jobs running that interfered with each other.
> Normally we handle lock conflicts by rolling back the transaction that
> got the lock conflict and retrying the same SQL statements. This is
> usually OK but with this particular rollback, the record with the
> conflict and the "lock conversion denied" error was not rolled back
> causing a primary key error in the next retry.
which should have stopped all active processing.
Normal deadlock and lock conflict error occur when concurrent
transactions attempt to change the same record.
A lock conflict is detected while the record manager is finding
the appropriate version of the record for the running transaction
and realizes that 1) there is a newer version than this transaction
can see and 2) this transaction wants to change the record. In the
normal case, the second transaction waits for the first to finish
and if the first commits, the second gets an error.
A deadlock occurs when one transaction has run into a lock
conflict and is waiting and then the other transaction also runs
into a lock conflict and is about to wait. If there's a circular
wait - transaction A waiting for B which is waiting for C which
is waiting for D which is waiting for A, then there's a deadlock
and one of the participants gets an error.
However, what you're seeing is a failure in the page handling -
internally Firebird does non-transactional page locking. Locks
are taken and released furiously. For some reason, the data page
(type 5) number 708341 is being held by a thread that can't
release it and requested in an incompatible mode by the transaction
that got the error. This should NEVER happen.
>Regards,
> Has anyone come across this error?
>
> We're running Firebird Classic 2.03 on Linux OpenSuse 10.2 x86-64 with
> about 150 connections during peak times.
>
Ann