Subject | Re: [IBO] How to prevent deadlock ??? |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2002-11-13T11:27:31Z |
Tanno,
there is no way you can eliminate deadlocks when two persons decide to
update the same record. When I buy groceries, I want to pay and exit as
quickly as possible, but I still have to stand in a queue if someone else
also want to do that (LockWait = True). Occationally I have no time to wait
and leave without getting my groceries (LockWait = False).
What you should do, is to make sure no transactions (especially those that
do updates) are running for a long time. As for your settings, LockWait
does influence its behaviour (should I wait and retry, or report the error
immediately?), but I think that the only way to completely eliminate
potential deadlocks would be to set readonly to true (which has the
side-effect that no-one can do any updates at all).
If it is a big problem, you should examine your design. Are there any
records that you update all the time and could this be changed (e.g. do you
have a table containing counts or sums)? Do you make certain that records
are always updated in the same order (e.g. it would be unfortunate if a
deadlock occured due to one transaction updating one record and failing to
update another, whereas another transaction updated the second record, but
failed updating the first - this could possibly lead to two transaction
waiting for eachother to complete)?
Set
At 11:32 13.11.2002 +0100, you wrote:
there is no way you can eliminate deadlocks when two persons decide to
update the same record. When I buy groceries, I want to pay and exit as
quickly as possible, but I still have to stand in a queue if someone else
also want to do that (LockWait = True). Occationally I have no time to wait
and leave without getting my groceries (LockWait = False).
What you should do, is to make sure no transactions (especially those that
do updates) are running for a long time. As for your settings, LockWait
does influence its behaviour (should I wait and retry, or report the error
immediately?), but I think that the only way to completely eliminate
potential deadlocks would be to set readonly to true (which has the
side-effect that no-one can do any updates at all).
If it is a big problem, you should examine your design. Are there any
records that you update all the time and could this be changed (e.g. do you
have a table containing counts or sums)? Do you make certain that records
are always updated in the same order (e.g. it would be unfortunate if a
deadlock occured due to one transaction updating one record and failing to
update another, whereas another transaction updated the second record, but
failed updating the first - this could possibly lead to two transaction
waiting for eachother to complete)?
Set
At 11:32 13.11.2002 +0100, you wrote:
>Hi all
>
>At updating a record one of the users of our system gets
> "lock conflict on no wait transaction deadlock"
>
>The TIB_Transaction has the following settings
>
> ServerAutoCommit := False;
> Isolation := tiCommitted;
> RecVersion := True;
> ReadOnly := False;
> LockWait := False;
>
>Should I change these settings to prevend deadlocks ?