Subject | Re: [firebird-support] Re: Commit Client Transaction - Monitoring Tables |
---|---|
Author | Slalom |
Post date | 2008-10-01T13:26:32Z |
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
[Non-text portions of this message have been removed]
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,No, two or more *transactions* attempting to modify a single record
>
>I was on the understanding that a lock conflict was a conflict between
>two statements attempting to modify a single record,
> something only..or an insert.
>possible during an update or delete (or by indirectly causing an
>update or delete inside a stored procedure or trigger).
>I can't otherwise imagine why a commit would ever be waiting, unlessIf 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.
>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.
./heLen
[Non-text portions of this message have been removed]