At 03:18 PM 7/26/2001 -0300, Marcos Vinicius Dufloth wrote:

>Yes, tanks too, but I yet have the opinion that the clause WAIT must be
>waiting for some period of time before raise an deadlock error.

If transaction A attempts to update a row that transaction B has already
changed, the WAIT option causes A to wait for B to end before reporting
an error to A. If B rolls back, A succeeds. If B commits, A gets a
Deadlock - update conflict error.

>deadlock error: update conflict would be renamed to something like "Time out
>lock error"

There's no timer involved - as long as B is open, A will wait.

>leave deadlock to truly deadlock, when A waits for a
>resource locked by B and B waits for a resource locked by A. Maybe this
>topic must be moved to ib-architect?

The update conflict is a secondary error for a reason buried in history.
At one point InterBase and several other databases shared error codes -
a source of major irritation - and we agreed on a small set of primary
errors, based on the recovery required. Since deadlock and update conflict
require the same sort of correction, they were combined.


Regards,

Ann
www.ibphoenix.com
We have answers.