Subject Re: [firebird-support] Re: Commit Client Transaction - Monitoring Tables
Author Slalom
I have changed my params to [concurrency, wait].   Based on my reading of the following article, it sounds like that is what I need:

http://www.firebirdsql.org/refdocs/langrefupd20-notes-withlock.html#langrefupd20-tbl-tpb-effects

Could someone explain what the rec_version params does or means?

----- Original Message ----
From: Helen Borrie <helebor@...>
To: firebird-support@yahoogroups.com
Sent: Tuesday, September 30, 2008 10:01:25 PM
Subject: Re: [firebird-support] Re: Commit Client Transaction - Monitoring Tables


At 11:45 1/10/2008, Adam wrote:

>Helen,
>
>I was on the understanding that a lock conflict was a conflict between
>two statements attempting to modify a single record,

No, two or more *transactions* attempting to modify a single record

> something only
>possible during an update or delete (or by indirectly causing an
>update or delete inside a stored procedure or trigger).

..or an insert.

>I can't otherwise imagine why a commit would ever be waiting, unless
>the OP is using a TRANSACTION COMMIT trigger that is attempting to
>perform an update or delete (either directly or indirectly via
>triggers or stored procedures). In this case, the reported scenario
>makes perfect sense, the transaction has a lock conflict to contend
>with and the OP has asked it to wait for the other transaction to
>commit or rollback first.

If the OP is using a WAIT transaction with Autocommit then any potential conflict will neither commit nor except when the COMMIT request is dispatched. Exactly what happens once the conflicting transaction commits (= posts and commits in IBX Autocommit terms) depends on other transaction settings (isolation and also RecVersion isoation is ReadCommitted) . If you have multiple ad hoc threads all hitting the same records all using WAIT you have a pretty high potential for deadlock conditions. With No Wait, a deadlock would except immediately and the application could resolve it. With WAIT, a deadlock readily becomes a livelock/deadly embrace: competing threads are all waiting and none can extricate itself.

./heLen


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