| Subject | Re: [firebird-support] Lock conflict on no wait transaction |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2005-07-07T15:23:25Z |
pungsven wrote:
The original error, the "lock conflict" is an application level problem
in which two concurrent transactions tried to update the same record.
That's a normal occurrence in a database. There are ways to avoid the
error, one of which is to perform a SELECT ... FOR UPDATE WITH LOCK on
the record you intend to modify. The select may fail, in which case I
suggest a hard commit - if you have work you want to save - followed by
retrying the select.
The second part of the error "internal gds software consistency check
(error during savepoint backout (290))" indicates a bug in Firebird.
You see it (I think) because part of your failure involved triggers and
stored procedures. The "savepoint backout" message refers to a list of
affected records that atomic actions (mass inserts, updates, deletes
plus procedures and triggers) carry around so their effects can be
undone on failure. Transactions also carry around a savepoint list to
undo their actions, but it is optional. In a statement that has several
undo lists involved, Firebird tries to keep count of how may parts of
the statement it has backed out, and when it gets to the transaction
level, it should have no more verb level lists. The error you saw was a
bug in that accounting, which was fixed in 1.5.2 (I think).
Regards,
Ann
>OK, you've got two problems.
> Today all the apps suddenly stopped working.
> In the firebird log I found the following:
> COMUNIT2003 (Server) Thu Jul 07 11:24:05 2005
> Database: E:\PROGRAM\DATALINK\CCASERVER\DB\CCA_DB.FDB
> lock conflict on no wait transaction
> deadlock
> update conflicts with concurrent update
> operation was cancelled
> internal gds software consistency check (error during savepoint
> backout (290))
The original error, the "lock conflict" is an application level problem
in which two concurrent transactions tried to update the same record.
That's a normal occurrence in a database. There are ways to avoid the
error, one of which is to perform a SELECT ... FOR UPDATE WITH LOCK on
the record you intend to modify. The select may fail, in which case I
suggest a hard commit - if you have work you want to save - followed by
retrying the select.
The second part of the error "internal gds software consistency check
(error during savepoint backout (290))" indicates a bug in Firebird.
You see it (I think) because part of your failure involved triggers and
stored procedures. The "savepoint backout" message refers to a list of
affected records that atomic actions (mass inserts, updates, deletes
plus procedures and triggers) carry around so their effects can be
undone on failure. Transactions also carry around a savepoint list to
undo their actions, but it is optional. In a statement that has several
undo lists involved, Firebird tries to keep count of how may parts of
the statement it has backed out, and when it gets to the transaction
level, it should have no more verb level lists. The error you saw was a
bug in that accounting, which was fixed in 1.5.2 (I think).
Regards,
Ann