Helllo



No, the cpu sources are free during this post. In precise, during my test 8
applications was in this endless loop trying to post, with some sleep()
during each post of course to avoid the cpu delays, the post commands didn't
show to use sources of cpu. The firebird seems to answer immediately
"deadlock".



Dennis





_____

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of slalom91
Sent: Tuesday, December 12, 2006 6:15 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Re: Issue: deadlock with Firebird and Delphi.
ref/eDN7002040583



--- In firebird-support@ <mailto:firebird-support%40yahoogroups.com>
yahoogroups.com, "Dennis" <dennis@...> wrote:

>
> Dear all
>
>
>
> I have made this test: there is small application that on its start

up

> updates the same record (with the same keys). When I call this

application

> instantly several times, for instance 15 times in less than

1/10second, some

> of these applications, about 4, occur the deadlock conflict error

on non

> wait transaction.
>
>
>
> At first sight, this is logical because some of them didn't commit

yet, so

> there are deadlock really, the problem is that using the follow

retry loop

> these launches cannot post even if the record became unlocked, even

if all

> other application / launches are terminated!
>
>
>
> The retry loop is like this:
>
>
>
> Usercancel:=false;
>
> Repeat
>
> Try
>
> Post;
>
> Ok:=true;
>
> Except
>
> If Dialog('retry?')=no then usercancel:=true;
>
> Ok:=false;
>
> End; // except
>
> Until ok or usercancel.
>
> If ok then commit;
>
>
>
> Transaction settings:
>
>
>
> read_committed
>
> rec_version
>
> nowait
>
>
>
> Error:
>
>
>
> lock conflict on no wait transaction
>
> deadlock
>
> update conflicts with concurrent update
>
>
>
> Note 1:
>
> In case where some applications cannot post because of deadlock, if

I call

> again the application (one more time), the new launch it updates the
> database with no error!!!
>
>
>
> Note 2:
>
> I produced the error by my own, leaving from other application the

record

> edited and uncommitted, the deadlock error occurred on tested

application,

> the loop worked as well, when I committed the transaction from the

other

> application, the loop posted the record and finally committed the
> transaction, so the loop is working.
>
>
>
> The fact is, an update with deadlock error, sometimes cannot be

always

> posted even if the record become unlocked from the other

application. This

> is not logical, where is the error?
>
>
>
> Please share your thoughts.
>
>
>
> Kind regards
>
> Dennis
>

Dennis,

This sounds very similar to the problem I have been experiencing
which I outlined in my post title "CPU Pegged.." maybe you could
verify with your test application that the CPU is maxed out when the
record is hanging and not posting.





[Non-text portions of this message have been removed]