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