Re: Strange record locking PROBLEMS
In article <9610171111.aa01153@qwsserv.qws.msk.su>, Victor says...
>
>Hi all,
>
>We are running INFORMIX (Online 7.10.UC1 and SE 7.12.UC1)
>on SCO UNIX (SCO_SV-3.2v5.0.0 and 3.2v4.2).
>
>
>Simplified test situation N 1 :
>-------------------------------
>
>CREATE DATABASE hangover WITH LOG;
>CREATE TABLE LockTable (locking_key INTEGER) LOCK MODE ROW;>{ ^^^^^^^^^^^^^ }
>{ ONLINE ONLY ! }
>{ Table created WITHOUT INDEXES ! }
>{ }
>INSERT INTO LockTable VALUES (1);
>INSERT INTO LockTable VALUES (2);>
>
>{ Process N 1 (via dbaccess) }
>BEGIN WORK;
>UPDATE LockTable SET locking_key = 1 WHERE locking_key = 1;>{ Transaction NOT COMMITTED. }
>
>{ Process N 2 (via dbaccess) after 'UPDATE N 1' is finished }
>BEGIN WORK;
>UPDATE LockTable SET locking_key = 2 WHERE locking_key = 2;>
>RESULT :
>244: Could not do a physical-order read to fetch next row.
>107: ISAM error: record is locked.>
>BUT if UNIQUE INDEX ON locktable(locking_key) created before updates
>result is OK (Process N 2 successfully updates row) !?
>
>QUESTION N 1 : Why ?
>^^^^^^^^^^^^^^^^^^^^
Victor,
Regarding case 1 :
Process 2 makes sequental scan as no indeces are available,
this result in error when it cannot retrieve locked error.
When index becomes available it runs OK which is fully expected.
Regarding case 2:
Personally I feel -211 is most disgusting error message I ever knew.
I do not have answer for this - please check locks (onstat -k) if it is with
Online. Hard to say without actually seeing it.
Cheers,
Ilya Bogorad,
DHL Systems Ltd. London/ UK
PS Chem tam zhivet i dyshit Moskva ?