home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2387 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  4.0 KB
  1. Path: sparky!uunet!gossip.pyramid.com!pyramid!infmx!cortesi
  2. From: cortesi@informix.com (David Cortesi)
  3. Newsgroups: comp.databases.informix
  4. Subject: The twin problem (was Re: HELP - Index Locks are creating DEADLOCKS)
  5. Message-ID: <1992Nov11.203538.29976@informix.com>
  6. Date: 11 Nov 92 20:35:38 GMT
  7. References: <4309@copper.Denver.Colorado.EDU> <OLIVER.92Nov10221419@snoopy.infix.de>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 89
  11.  
  12. In article <OLIVER.92Nov10221419@snoopy.infix.de> oliver@infix.de (Oliver Okrongli) writes:
  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....
  17. >
  18. >>     The error messages are ISAM 154 and isql -271, -245
  19. >
  20. >We are also facing similar locking problems which may or may not be
  21. >related to yours (error numbers tend to vary between different
  22. >releases).
  23.  
  24. Purely a side issue, but this is in general not true. Error
  25. numbers are very stable.  Sometimes an error number is retired
  26. because the condition no longer occurs. Often new error
  27. conditions are added, and these sometimes re-use the error
  28. numbers of old, no-longer-occurring, conditions.  For example
  29. in version 5.0, some of the error conditions related to the
  30. new referential integrity features re-used error numbers that
  31. had been retired effective with version 4, 2 years earlier.
  32.  
  33. But as long as the error cause is the same, the number is the same.
  34.  
  35. >  Our number 1 problem is: when a row gets locked sometimes
  36. >rows next to it are locked also.  This leads to unpredictable locks
  37. >especially on installations with a larger number of active users.
  38. >
  39. >We talked to our Informix distributor providing support here in
  40. >Germany.  They said the problem is known at Informix as the 'sibling
  41. >problem' but is considered a feature.
  42.  
  43. Sibling problem, twin problem, same thing.  The essence is that an
  44. index key has been changed (updated or deleted) as part of a
  45. transaction which is not yet complete.  Since the transaction could
  46. still be rolled back, there has to be some way to reserve the original
  47. key value, so that no other transaction will attempt to use it.
  48. However: the original key value is no longer in the database.
  49.  
  50. The method used is to place a lock on the next higher index entry,
  51. and to require any transaction that would insert a value to 
  52. acquire a lock on the adjacent key.  This ensures that no other
  53. process can insert the original key until the first transaction
  54. completes.
  55.  
  56. Unfortunately it can also prevent another transaction from
  57. inserting an unrelated key that merely happens to fall in the
  58. same span of existing keys.
  59.  
  60. Note: this was documented in an issue of Tech Notes sometime in 1988
  61. (I remember because it was one of the first pieces of tech writing
  62. I did at Informix :-) The twin problem is not a new issue!
  63.  
  64. >  The officially assigned case
  65. >number at Informix is 11473.  We have been told that there is no
  66. >schedule to correct this problem.
  67.  
  68. As Dave Kosenko posted here earlier, a different mechanism will
  69. be used effective with version 6.0.
  70.  
  71. >The problem has been verified to occur on the following engines
  72. >    OnLine 4.0 on i486,
  73. >    OnLine 5.0 on HP9000/700
  74. >and to a lesser extent also on
  75. >    SE 4.0 on i486.
  76.  
  77. The "lesser extent" has to be purely a matter of luck and timing, since
  78. the logic is the same in all engines.
  79.  
  80. >We do consider these effects extremely undesirable because they lead
  81. >to unpredictable application behaviour.  We are currently not aware of
  82. >any workaround.
  83.  
  84. There is no basic difference between a lock conflict based on the twin
  85. problem and one caused by two processes trying to update the same row.
  86. Both result from two processes attempting to seize the same resource at
  87. the same time.
  88.  
  89. It seems to me in my ignorance that this lock conflict could be
  90. handled exactly like a lock conflict from any other source.
  91. You could either
  92.     * run with SET LOCK MODE TO WAIT
  93. or
  94.     * when any operation discovers a lock conflict, roll
  95.       the transaction back and retry it.
  96.  
  97. Is this not so?
  98.  
  99. Dave Cortesi
  100.   cortesi@informix.com
  101.