🚀 go-pugleaf

A deadlock is when a statement (i.e. UPDATE) locks for example row 1 and
then tries to update row 2.
In the mean time another user has locked and edited row 2 and now tries to
update row 1.

So, row 1 is locked by user 1 and row 2 is locked by user 2 who are now both
waiting for the other user to release the lock.

The situation in your last sentence will (in my option) not generate a error
because the second statement will wait till the records are release from the
lock and either 1) try to delete or update a row that already is deleted (=
no problem) or 2) update or delete a row that is updated which will not
generate a database error but you should write your software to prevent
this. (i.e. check how much rows are edited / deleted after the stament and
compare this to what you expect)

Hope this helps,

Greetings,
Thomas

"Edward Diener" <eddielee@tropicsoft.com> wrote in message
news:3dff68ba$1@newsgroups.borland.com...
> What does the IB isc_deadlock error mean ? What is the difference between
it
> and isc_lock_conflict ? If TXA updates or deletes a record and TXB
attempts
> to update or delete that record before TXA has finished, what IB error
> message is received in the exception ?
>
>

"T. van Rompaey" <tvrompaey@scabbouw.nlNOSPAM> wrote in message
news:3e032c57$1@newsgroups.borland.com...
> A deadlock is when a statement (i.e. UPDATE) locks for example row 1 and
> then tries to update row 2.
> In the mean time another user has locked and edited row 2 and now tries to
> update row 1.
>
> So, row 1 is locked by user 1 and row 2 is locked by user 2 who are now
both
> waiting for the other user to release the lock.

I didn't realize IB could detect this and generate an error. I guess this is
the isc_deadlock error.

>
> The situation in your last sentence will (in my option) not generate a
error
> because the second statement will wait till the records are release from
the
> lock and either 1) try to delete or update a row that already is deleted
(=
> no problem) or 2) update or delete a row that is updated which will not
> generate a database error but you should write your software to prevent
> this. (i.e. check how much rows are edited / deleted after the stament and
> compare this to what you expect)

From my understanding it will wait only if one uses "read_committed",
"no_rec_version", and "wait" transaction attributes or one uses
"consistency" and "wait", else an error is produced when the second
transaction attempts to delete or update the record before the first
transaction commits. I guess this error is the isc_lock_conflict.

Thanks. The two cases explain the different errors.

A bit of additional information. There is a setting in the ibconfig
file that lets you control how long IB will wait for a lock before it
performs a deadlock scan.


--
Bill (TeamB)
(TeamB cannot respond to questions received via email)

OK, thanks for the info.

"Bill Todd" <bill@notthis.dbginc.com> wrote in message
news:qj570vsp6a89g6dmfst156ohlr68ig1med@4ax.com...
> A bit of additional information. There is a setting in the ibconfig
> file that lets you control how long IB will wait for a lock before it
> performs a deadlock scan.