Yes, this must be happened! Thank you for your advise.



Dennis



_____

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



Seems simple enough.

1) You start transaction 1.
2) You start transaction 2.
3) Transaction 2 makes a change.
4) Transaction 1 tries to make a change. Since transaction 2 has changed
the record since transaction 1 started, you get an error upon post.
5) Transaction 2 commits.
6) Transaction 1 retries the change. Even though transaction 2 has
committed, this doesn't change the fact that transaction 2 has changed
the record since transaction 1 started.

I think this may have to do with transaction isolation. Changes done in
transaction 2 may not be visible in transaction 1, and then it could be
insane to allow the change getting true (suppose a bank account with 40
euro in it, transaction 1 tries to add 20 to it, whereas transaction 2
tries to remove 20. Transaction 2 changes the balance to 20 euro and
commits, whereas transaction 1 cannot see this change tries to change it
to 60 euro).

If you rolled back the transaction and redid your changes in your loop,
you wouldn't run into this kind of trouble.

HTH,
Set

Dennis wrote:

> Hello guys, I still have no response from anyone, is it so strange?

Doesn't

> anybody have faced similar problem?
>
>
>
> Thank you in advance
>
> Dennis
>
>
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>

yahoogroups.com

> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>

yahoogroups.com] On Behalf Of Dennis

> Sent: Friday, December 08, 2006 10:28 AM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>

yahoogroups.com

> Subject: [firebird-support] Issue: deadlock with Firebird and Delphi.
> ref/eDN7002040583
>
>
>
> 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

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