Subject | Re: [ib-support] Deadlock and wait |
---|---|
Author | Marcos Vinicius Dufloth |
Post date | 2001-07-26T19:01:16Z |
Ok. Now I understand how it works. Tanks. :o)
Dufloth.
Dufloth.
----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <ib-support@yahoogroups.com>
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
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.
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>