home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2353 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  4.8 KB
  1. Path: sparky!uunet!ukma!netsys!decwrl!gossip.pyramid.com!pyramid!infmx!davek
  2. From: davek@informix.com (David Kosenko)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: *** HELP - Index Locks are creating DEADLOCKS ***
  5. Message-ID: <1992Nov9.172454.22610@informix.com>
  6. Date: 9 Nov 92 17:24:54 GMT
  7. References: <4309@copper.Denver.Colorado.EDU>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 98
  11.  
  12. K Lonz writes:
  13. >Subject: INDEX LOCKS are creating DEADLOCKS
  14. >         Index Lock conflicts
  15. >
  16. >Problem Summary:
  17. >
  18. >    We are experiencing a deadlock and subsequent abort with users
  19. >    who are adding/modifying data in the same table.  The table is indexed
  20. >    on sequential numbers.  The users are adding/modifying data records
  21. >    where the sequential numbers are close to each other.  We suspect that
  22. >    the indexes are using page locking - which is causing our problem.
  23.  
  24. If that is the case, and the cause, alter your table to use row locking.
  25.  
  26. >
  27. >    The error messages are ISAM 154 and isql -271, -245
  28.  
  29. Unless you are using I-Star and performing distributed updates, the -154 is
  30. a bit of a misleading error.  More on this in a bit.
  31.  
  32. >
  33. >Problem (Step-by-step):
  34. >
  35. >    1.  User 1 begins a Multi-Statement Transaction (mst) which takes
  36. >        several minutes to perform, and navigates through several screens.
  37. >
  38. >        Note: The (mst) modifies and adds data in a row-locked table,
  39. >              indexed on sequentially assigned integers.
  40. >
  41. >    2.  User 1 acquires an index lock (in a transaction) which will
  42. >        last several more minutes.  (tbstat -u, flag 2 changes from B to T).
  43. >
  44. >    3.  User 2 begins another (mst) to add/modify data in the same table.
  45. >        The record has the next sequential number (or a very close number).
  46. >
  47. >    4.  User 2 attempts to do work but waits for the index lock to be freed
  48. >        up from User 1.  (The add/modify row is different)
  49. >
  50. >    5.  User 2 aborts after the deadlock time limit is exceeded.
  51.  
  52. There is no such thing as a deadlock timeout on local transactions - it
  53. applies only to distributed transactions where a  deadlock cannot be truly
  54. detected.  For local access, a deadlock is aborted as soon as it is 
  55. detected (actually more technically, a deadlock is not allowed to happen -
  56. the transaction is aborted when the server realizes that granting a lock will
  57. result in a deadlock). Also note that deadlocks can only happen when you
  58. choose to wait for locks (SET LOCK MODE TO WAIT [##]).
  59.  
  60. >    1.  Most Importantly:
  61. >        Does someone have an alternative solution?
  62. >
  63. >    2.  Do indexes use page locking exclusively or
  64. >        can indexes be 'tuned' to use row locking?
  65.  
  66. If the table is created using (or altered to use) row locking, both rows and
  67. indexes are locked at the "item" level (ro rows, an "item" is the row, for
  68. indexes it is the key/pointer entry in the b+tree).
  69.  
  70. >    3.  We know that solution #4 above is quirky, but we
  71. >        would like some feedback on it if there is any out
  72. >        there.
  73.  
  74. Based on the error message you are getting (-154) and assuming that you are
  75. *not* doing distributed queries (you didn't mention that you are), then the
  76. cause of your problem is likely that you have used SET LOCK MODE TO WAIT ##,
  77. i.e. you are waiting on locks with a timeout.  The length of the transactions
  78. are causing that timeout to be exceeded, so the waiting transaction aborts.
  79. To cure this either increase the WAIT time, or WAIT with no timeout
  80. (SET LOCK MODE TO WAIT).
  81.  
  82. By the way, if you were encountering a REAL deadlock, you would be receiving
  83. ISAM error -143.
  84.  
  85. On -154:
  86. Unfortunately, the -154 error was used for two different events that are
  87. siliar from a low-level perspective, but very different from a user's
  88. perspective.  The first, and the one the "message" really applies to, is
  89. when a distributed transaction waits "too long" to acquire a lock on 
  90. a remote server.  Since it cannot interrogate the remote server's shared 
  91. memory to detect a deadlock situation, it assumes this "too long" wait
  92. indicates a deadlock situation (this wait time is tuned via 
  93. DEADLOCK_TIMEOUT in tbconfig).  The other is, as I have mentioned above,
  94. when you specify to wait for locks with a timeout, e.g. SET LOCK MODE TO
  95. WAIT 30, which will wait on a lock for 30 seconds, then return an error if
  96. it doesn't get the lock in that amount of time.  This is not because of
  97. a deadlock, potential or otherwise, since the lock would not be granted if
  98. a deadlock would result, but rather a user choice to give up waiting for
  99. the lock after a certain amount of time.  Both return the same error code
  100. (-154).
  101.  
  102. I hope this is of some help.
  103.  
  104. Dave
  105. -- 
  106. Disclaimer: These opinions are not those of Informix Software, Inc.
  107. **************************************************************************
  108. "I look back with some satisfaction on what an idiot I was when I was 25,
  109.  but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
  110.