home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2379 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.8 KB  |  110 lines
  1. Newsgroups: comp.databases.informix
  2. Path: sparky!uunet!mcsun!chsun!bernina!schiele
  3. From: schiele@bernina.ethz.ch (Thomas Schiele)
  4. Subject: Re: *** HELP - Index Locks are creating DEADLOCKS ***
  5. Message-ID: <1992Nov11.120353.14284@bernina.ethz.ch>
  6. Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
  7. References: <4309@copper.Denver.Colorado.EDU> <1992Nov9.111120.25041@bernina.ethz.ch> <1992Nov10.160339.29203@informix.com>
  8. Date: Wed, 11 Nov 1992 12:03:53 GMT
  9. Lines: 99
  10.  
  11. Informix: Locks and Indexes
  12.  
  13.  
  14. Thanks for the fast response and the competent feedback.
  15.  
  16.  
  17. David Kosenko writes:
  18. >>2. There are conflicts between insert and/or delete operations because
  19. >>   row level locks affect neighbour tuples in the index (side effect
  20. >>   called 'feature'!). ...
  21. >>   ...
  22. >This is basically tru, and is an unpalatable side-effect of this locking
  23. >strategy. Again, Informix recognizes this and is re-engineering it for our
  24. >6.0 release.
  25. Thank you for the information about the 6.0 release :-)
  26.  
  27.  
  28. >Perhaps you could describe your application, in order to allow others to
  29. >understand what you are trying to accomplish. You would then be more likely
  30. >to receive useful suggestions.
  31.  
  32. Ok. We have an application where users (processes) do not only selects
  33. but also updates, inserts and deletes in transaction mode. In order to
  34. demonstrate the problem let's use the following simplified example:
  35.  
  36. The test database: 
  37.    CREATE DATABASE test WITH LOG;
  38.    CREATE TABLE rel (
  39.       id CHAR(1),
  40.       data CHAR(10)
  41.    ) 
  42.    LOCK MODE ROW;
  43.    INSERT INTO rel VALUES ("1", "one");
  44.    INSERT INTO rel VALUES ("2", "two");
  45.    INSERT INTO rel VALUES ("3", "three");
  46.    INSERT INTO rel VALUES ("4", "four");
  47.    INSERT INTO rel VALUES ("5", "five");
  48.  
  49. Example 1:
  50.    We use the test database.
  51.    User A does the following and stays in transaction mode:
  52.       BEGIN WORK;
  53.       DELETE FROM rel WHERE id = "2";
  54.  
  55.    User B does the following:
  56.       BEGIN WORK; 
  57.       DELETE FROM rel WHERE id = "4"; 
  58.       result: 244: Could not do a physical-order read to fetch next row.
  59.               107: ISAM error: record is locked.
  60.    It doesn't seem to work as expected.
  61.  
  62. Example 2:
  63.    We use our test database.
  64.    We install an index in our test database:
  65.       CREATE INDEX relind ON rel (
  66.          id
  67.       );
  68.  
  69.    User A does the following and stays in transaction mode (same as above): 
  70.       BEGIN WORK; 
  71.       DELETE FROM rel WHERE id = "2"; 
  72.     
  73.    User B does the following::   
  74.       BEGIN WORK;  
  75.       DELETE FROM rel WHERE id = "4";  
  76.       result: 1 row(s) deleted.
  77.    It works as expected/
  78.  
  79. (remark: the delete statements in the examples above are used to place
  80.          exclusive locks.)  
  81.  
  82. >What you may be seeing is this: using higher isolation levels (REPEATABLE
  83. >READ) will cause table level locks to be placed when queries do not use
  84. >indexes. This is actually an optimization, believe it or not: since RR
  85. >locks all rows examined, and a non-indexed read must examine every row.  In
  86. >such a case, a table lock is much less costly.
  87.  
  88. Just some questions:
  89. 1. Does this mean that the delete statement of user A in example 1 places
  90.    an exclusive lock on the table?
  91. 2. Or does this mean that the delete statement (or select etc.) places
  92.    locks on all rows (shared or exclusive locks) before (!) evaluating
  93.    the WHERE clause? (I can't imagine that :-) )
  94.    Or does this even mean that informix uses the "optimization" mentioned
  95.    above to prevent exaclty that effect?
  96. 3. Does this mean that I have to use an index as demonstrated in example 2
  97.    to turn off the "optimization" with table locks in order to get row
  98.    level locking?
  99. 4. If question 3 can be answered with yes, then why is my statement
  100.    "Row level locking works only if you use an index on that table"
  101.    completely false?
  102.  
  103.  
  104. cu THGSCH
  105. ---------------------------------------------
  106. Thomas G. Schiele
  107. Winterthurerstrasse 297
  108. CH-8057 Zuerich
  109. Switzerland
  110.