home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2376 < prev    next >
Encoding:
Text File  |  1992-11-10  |  3.5 KB  |  95 lines
  1. Newsgroups: comp.databases.informix
  2. Path: sparky!uunet!mcsun!Germany.EU.net!rz.uni-hildesheim.de!agsc!erni.escape.de!infix!oliver
  3. From: oliver@infix.de (Oliver Okrongli)
  4. Subject: Re: *** HELP - Index Locks are creating DEADLOCKS ***
  5. In-Reply-To: klonz@copper.denver.colorado.edu's message of 7 Nov 92 14:50:31 GMT
  6. Message-ID: <OLIVER.92Nov10221419@snoopy.infix.de>
  7. Sender: oliver@infix.uucp (Oliver Okrongli)
  8. Organization: infix Software-Systeme GmbH
  9. References: <4309@copper.Denver.Colorado.EDU>
  10. Date: Tue, 10 Nov 1992 21:14:19 GMT
  11. Lines: 82
  12.  
  13. >>>>> On 7 Nov 92 14:50:31 GMT, klonz@copper.denver.colorado.edu (K Lonz) said:
  14.  
  15. >     We are experiencing a deadlock and subsequent abort with users
  16. >     who are adding/modifying data in the same table.  The table is indexed
  17. >     on sequential numbers.  The users are adding/modifying data records
  18. >     where the sequential numbers are close to each other.  We suspect that
  19. >     the indexes are using page locking - which is causing our problem.
  20.  
  21. >     The error messages are ISAM 154 and isql -271, -245
  22.  
  23. We are also facing similar locking problems which may or may not be
  24. related to yours (error numbers tend to vary between different
  25. releases).  Our number 1 problem is: when a row gets locked sometimes
  26. rows next to it are locked also.  This leads to unpredictable locks
  27. especially on installations with a larger number of active users.
  28.  
  29. We talked to our Informix distributor providing support here in
  30. Germany.  They said the problem is known at Informix as the 'sibling
  31. problem' but is considered a feature.  The officially assigned case
  32. number at Informix is 11473.  We have been told that there is no
  33. schedule to correct this problem.
  34.  
  35. The problem has been verified to occur on the following engines
  36.     OnLine 4.0 on i486,
  37.     OnLine 5.0 on HP9000/700
  38. and to a lesser extent also on
  39.     SE 4.0 on i486.
  40.  
  41. With OnLine we use row level locking exclusively.  We have verified
  42. that page level locking results in a higher failure rate.  SE uses row
  43. level locking exclusively.
  44.  
  45. The following code fragments should confirm this (using OnLine)
  46.  
  47. Step 1: Create our test database:
  48.     create database test with log;
  49.     create table tab1
  50.        (
  51.         col1 integer,
  52.         col2 integer
  53.        ) lock mode row;
  54.     create index i1 on tab1 (col2);
  55.     insert into tab1 values (1, 1);
  56.     insert into tab1 values (2, 2);
  57.  
  58. Step 2: Lock row (1, 1) with this update cursor:
  59.     declare uc cursor for
  60.        select col1
  61.           into $col1
  62.           from tab1
  63.           where col2 = 1
  64.           for update of col1;
  65.  
  66. Step 3: Start a second process using the following update statement:
  67.     update tab1
  68.        set col2 = -col2
  69.        where col1 = 2;
  70.  
  71.     This will produce the following error (OnLine) although row
  72.     (2,2) should be still unlocked:
  73.     -244: Could not do a physical-order read to fetch next row.
  74.     -107: ISAM error:  record is locked.
  75.  
  76. Step 4: Now repeat steps 1 to 3 replacing the index statement with:
  77.     create index i1 on tab1 (col1);
  78.  
  79.     No error should occur.
  80.  
  81. Unpredictable locks with the same consequences as noted above are
  82. generated by DELETE statements locking the `next, or adjacent key,
  83. value in the index' as documented in OnLine literature.
  84.  
  85. We do consider these effects extremely undesirable because they lead
  86. to unpredictable application behaviour.  We are currently not aware of
  87. any workaround.
  88.  
  89. We would appreciate any kind of recommendations - especially from
  90. within Informix US (Alan are you listening?)
  91. -- 
  92. Oliver Okrongli        infix Software-Systeme GmbH      Phone +49 531 238090
  93.             Rebenring 33              Fax   +49 531 3801152
  94. oliver@infix.de        D-W-3300 Braunschweig          F.R. Germany
  95.