Subject | Re: [IBO] [IB_SQL] How to use IB_SQL like SqlMonitor |
---|---|
Author | Stefano Campri |
Post date | 2003-06-17T10:57Z |
> > i have yet got the long -awaite deadlockI'm sure !!! i tried it
> > locking the record via IB_SQL and
> > posting a new record from the test application
> >
> > Now i have a new one question :
> >
> > Setting LockWait = true the deadlock error is raised only when the
> > lock condition is removed
> Are you sure?
i know it's strange but that's what's happen
>I'm not talking from my own experience here, but myi thought like you
> understanding is that if LockWait is true, the transaction just waits
> until the lock has been removed (no matter how long it takes), and
> then does whatever it has to do. So you'll only set LockWait to true
> if you're pretty sure that any locks will be quickly removed (like in
> the now famous example).
> If an error is raised, I guess it can't be a lock error (unlessi get a deadlock error :(
> there's some built-in timeout)
what do you mean with built-in timeout ?
Do you mean any value in TIB_Transaction.TimeOutProps ?
could be this built-in timeout raising the
deadlock after removing the lock condition ?
> If LockWait is false and there is a lock, am error will be raisedi thought so, but i had to write some code in TIB_Queery.OnPostError
> immediately. You can then have your code retry after some time... or
> not... or ask the user...
> > is it correct to intercept the deadlock and handle it
> > in the TIB_Queery.OnPostError ?
> I suppose so, since the conflict will arise upon posting.
> > what's the best solution to intercept the deadlock
> > and try to post again ?
> If - like in the example - you know that locks will only exist for a
> limited time, the simplest thing seems setting LockWait to true.
because the deadlock error raise after removing the lock condition
Any help would be appreciate
Thanks in advance,
Stefano Campri
> Greetings,
> Paul Vinkenoog