home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2340 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.9 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!csn!copper!klonz
  2. From: klonz@copper.denver.colorado.edu (K Lonz)
  3. Newsgroups: comp.databases.informix
  4. Subject: *** HELP - Index Locks are creating DEADLOCKS ***
  5. Message-ID: <4309@copper.Denver.Colorado.EDU>
  6. Date: 7 Nov 92 14:50:31 GMT
  7. Organization: University of Colorado at Denver
  8. Lines: 74
  9.  
  10.  
  11. Subject: INDEX LOCKS are creating DEADLOCKS
  12.          Index Lock conflicts
  13.  
  14. Background:
  15.  
  16.     We're running Informix 4.1 on an Amdahl UTS.
  17.     We're enhancing and modifying a system which was originally
  18.     developed and used on 2.1.
  19.  
  20. Problem Summary:
  21.  
  22.     We are experiencing a deadlock and subsequent abort with users
  23.     who are adding/modifying data in the same table.  The table is indexed
  24.     on sequential numbers.  The users are adding/modifying data records
  25.     where the sequential numbers are close to each other.  We suspect that
  26.     the indexes are using page locking - which is causing our problem.
  27.  
  28.     The error messages are ISAM 154 and isql -271, -245
  29.  
  30. Problem (Step-by-step):
  31.  
  32.     1.  User 1 begins a Multi-Statement Transaction (mst) which takes
  33.         several minutes to perform, and navigates through several screens.
  34.  
  35.         Note: The (mst) modifies and adds data in a row-locked table,
  36.               indexed on sequentially assigned integers.
  37.  
  38.     2.  User 1 acquires an index lock (in a transaction) which will
  39.         last several more minutes.  (tbstat -u, flag 2 changes from B to T).
  40.  
  41.     3.  User 2 begins another (mst) to add/modify data in the same table.
  42.         The record has the next sequential number (or a very close number).
  43.  
  44.     4.  User 2 attempts to do work but waits for the index lock to be freed
  45.         up from User 1.  (The add/modify row is different)
  46.  
  47.     5.  User 2 aborts after the deadlock time limit is exceeded.
  48.  
  49. Desired Behavior:
  50.  
  51.     The users must be able to add/modify records without encountering
  52.     the deadlocks.  We would like to retain the (mst)'s and not implement
  53.     a major revision of the code.
  54.  
  55. Possible Answers:
  56.  
  57.     1.  Ignore the problem - obviously unacceptable.
  58.     2.  Disable the indexes - :( - also unacceptable.
  59.     3.  Rewrite application without (mst)'s - not enough time and
  60.         undesirable at best.
  61.     4.  Allocate integers non-sequentially in the hopes of not running
  62.         into the page locks.  (We know - we're grasping!)
  63.  
  64.  
  65. Can anyone help:
  66.  
  67.     1.  Most Importantly:
  68.         Does someone have an alternative solution?
  69.  
  70.     2.  Do indexes use page locking exclusively or
  71.         can indexes be 'tuned' to use row locking?
  72.  
  73.     3.  We know that solution #4 above is quirky, but we
  74.         would like some feedback on it if there is any out
  75.         there.
  76.  
  77. Thanks in advance!
  78.  
  79. -- 
  80. Michael Klonecki                                     Life is a gift.
  81. 1391 S. Argonne Circle          
  82. Aurora, CO  80017-4418                               Choose wisely what to 
  83. klonz@copper.denver.colorado.edu                     do with your gift. 
  84.