home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2349 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.7 KB  |  62 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: <1992Nov9.111120.25041@bernina.ethz.ch>
  6. Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
  7. References: <4309@copper.Denver.Colorado.EDU>
  8. Date: Mon, 9 Nov 1992 11:11:20 GMT
  9. Lines: 51
  10.  
  11. Informix: Locks and Indexes 
  12.  
  13. I've noticed the following points using Informix Version 4:
  14. 1. Even if you use the option 'LOCK MODE ROW' in the SQL statement 'CREATE
  15.    TABLE', the database will use table locks! There is no row level
  16.    locking. 
  17.    Row level locking works only if you use an index on that table. 
  18. 2. If you delete a row, the next row in the index (!) will be locked too.
  19. 3. A row can be inserted only if the next tuple in the index (!) is not 
  20.    locked.
  21.    Row level locking works only if you use an index on that table. 
  22.    
  23. I've found in the complete documentation for Informix one (!) remark only:
  24.    "A process running under Informix-OnLine acquires an exclusive 
  25.    lock on a row before it updates a table, deletes a row, or inserts
  26.    a row. A exclusive lock prevents another process from modifying the
  27.    contents of the row before the lock is released. The delete process
  28.    also locks the next, or adjacent key, value in the index. This
  29.    feature ensures that another process does not insert a row with
  30.    the same value as the deleted key until the lock is released. The
  31.    insert process acquires an exclusive lock on the row and checks to 
  32.    make sure that the next, or adjacent key, values are not locked. If
  33.    the values are locked, then the insert fails." (Informix-OnLine
  34.    Administrator's Guide)
  35.  
  36. My remarks:   
  37. 1. Row level locking works with indexes only. You have to use an index 
  38.    even if you don't need it.
  39.    It seems that locking is implemented via ISAM index locking. 
  40. 2. There are conflicts between insert and/or delete operations because   
  41.    row level locks affect neighbour tuples in the index (side effect
  42.    called 'feature'!). Deleting the last row in the index even locks 
  43.    the index to the end, no more rows can be inserted.
  44. 3. There are no hints in the documentation which strategy to use for   
  45.    defining an index in order to have correct row level locking.
  46.    For example it is not defined, whether one must use all fields of
  47.    all WHERE clauses (!) of a whole application (!!) to have correct row
  48.    level locking. It is even not defined how locking works if there is 
  49.    more than one index on a table.
  50.  
  51. >>Can anyone help:
  52. ...I need some help too (or is this really a 'feature' of informix?)...
  53.  
  54.  
  55. cu Thomas
  56. -----
  57. Thomas G. Schiele
  58. Winterthurerstrasse 297
  59. CH-8057 Zuerich
  60. Switzerland
  61. schiele@bernina.ethz.ch
  62.