|Subject||Re: [ib-support] Deadlock and wait|
|Author||Marcos Vinicius Dufloth|
Ok. Now I understand how it works. Tanks. :o)
----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
Sent: Thursday, July 26, 2001 3:39 PM
Subject: Re: [ib-support] Deadlock and wait
> 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
> >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
> require the same sort of correction, they were combined.
> We have answers.
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.