A deadlock occurs when two concurrent processes request the same resources in different sequences. So the process holds a resource that the other process requires if it is to complete.

To eliminate deadlocking, always request resources in the same order within a transaction. I like alphabetically by table name since it is easy to remember.

----- Original Message -----
From: Alexander V.Nevsky
To: firebird-support@yahoogroups.com
Sent: Monday, February 16, 2004 3:31 AM
Subject: [firebird-support] Re: Everything about transaction


--- In firebird-support@yahoogroups.com, "James@B..." <james@b...>
wrote:
> i want to know about how transction works and how can i optimise my
c/s programs with this.

James, most full and precise free available description I know is
IB6 Open Source API Guide chapter Working With Transaction. For more
popular description search articles at www.ibphoenix.com and
www.cvalde.net .

> read_committed
> rec_version
> nowait
> SHARED

Last have nothing to do with read_commited isolation level, it is
parameter for table-blocking consistency one.

> it some times gives deadlock on some views.

Data modifications on updatable views, I suppose. This only mean
update conflicted with another uncommited update, you can do nothing
against nature :), just serve such a conflicts in your applications.

Best regards,
Alexander.



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