Subject | Re: lock conflict on no wait transaction |
---|---|
Author | Adam |
Post date | 2008-01-17T22:35:21Z |
--- In firebird-support@yahoogroups.com, "Erick Sasse" <esasse@...> wrote:
record.(**1) This may be happening explicitly by your application, or
implicitly by triggers being fired by queries you are running. Lock
conflicts are an 'expected exception' in any multi-user system. It is
up to your application to implement retry logic (if that is what you
want). It is also advisable to make your transactions as short as
possible to reduce the length of time the records are 'locked'.
Adam
(**1) There is also a 'feature' in Firebird where updating the parent
record from transaction A will prevent transaction B from inserting a
record into the child table, even if transaction A doesn't touch the
referenced PK which causes this exception. This is because Firebird
only knows the parent record has been modified, and can not tell
whether the primary key was.
>You have two transactions competing to update/delete the same
> How can I avoid this error?
>
> lock conflict on no wait transaction
> deadlock
> update conflicts with concurrent update
>
> Thanks.
record.(**1) This may be happening explicitly by your application, or
implicitly by triggers being fired by queries you are running. Lock
conflicts are an 'expected exception' in any multi-user system. It is
up to your application to implement retry logic (if that is what you
want). It is also advisable to make your transactions as short as
possible to reduce the length of time the records are 'locked'.
Adam
(**1) There is also a 'feature' in Firebird where updating the parent
record from transaction A will prevent transaction B from inserting a
record into the child table, even if transaction A doesn't touch the
referenced PK which causes this exception. This is because Firebird
only knows the parent record has been modified, and can not tell
whether the primary key was.