home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / theory / 358 < prev    next >
Encoding:
Text File  |  1992-08-12  |  3.2 KB  |  60 lines
  1. Newsgroups: comp.databases.theory
  2. Path: sparky!uunet!psinntp!spunky!jfr
  3. From: jfr@redbrick.com (Jon Rosen)
  4. Subject: Re: Optimistic Concurrency Control
  5. Message-ID: <1992Aug12.162027.18142@redbrick.com>
  6. Organization: Red Brick Systems, Los Gatos, CA
  7. References: <DAVIDM.92Aug10113706@consilium.com> <1992Aug11.050133.23420@redbrick.com> <Bsu6u4.3vr@wpi.WPI.EDU>
  8. Date: Wed, 12 Aug 1992 16:20:27 GMT
  9. Lines: 49
  10.  
  11. In article <Bsu6u4.3vr@wpi.WPI.EDU> rcarter@wpi.WPI.EDU (Randolph Carter <Joseph H. Allen>) writes:
  12. >jfr@redbrick.com (Jon Rosen) writes:
  13. >>In article <DAVIDM.92Aug10113706@consilium.com> davidm@consilium.com (David S. Masterson) writes:
  14. >>>>>>>> On 9 Aug 92 20:52:20 GMT, davidw@cascade.demon.co.uk (David Wilkinson)
  15. >>>>>>>> said:
  16. >>>> Does anyone know of any references about optimistic concurrency control in
  17. >>>> distributed database systems? I've read lots about the theory, but would
  18. >>>> like to know how it works out in practice.
  19. >
  20. >>>We used optimistic locking in our system in order to prevent locking the
  21. >>>database while a human-speed transaction was going on.
  22. >
  23. >>  We are investigating optimistic concurrency as a form of locking for
  24. >>  our relational query database management system
  25. >
  26. >Does (can) the application program itself retry when rollback occures?  I'm
  27. >curious about the implication to users in systems where transactions fail
  28. >and must be retried.  I know this is a standard technique in RDMS, but I can
  29. >think of examples of systems where this is unacceptable.  So I'm just
  30. >wondering if applications which use databases with modern concurrency
  31. >control techniques are written to attempt retries themselves or if they
  32. >usually abort all the way back to the user.  The textbooks I've read imply
  33. >that they abort all the way back to the user (that they have to "resubmit"
  34. >the transaction).  Perhaps they abort all they back to the user but remember
  35. >the data entered in the transacation so that the user only has to hit a
  36. >retry key?
  37.  
  38.  Of course, that all depends on the application.  First of all, any 
  39.  reasonable SQL application (I am assuming SQL here but other data
  40.  access languages would be included as well) must be prepared for
  41.  any statement to fail for a number of reasons.  In some cases, the
  42.  application may be able to determine that it is possible to retry
  43.  the transaction.  In others, it will be necessary to alert the user.
  44.  This depends on what the transaction is doing.  For instance, in an
  45.  ATM application, if the transaction aborted because the balance
  46.  record had been updated by another transaction between the first
  47.  transaction's read and its attempted update, this could be a pretty
  48.  serious situation if you don't alert the "user" (i.e., customer -
  49.  maybe s/he doesn't want to withdraw money if s/he found out the
  50.  actual balance was lower than expected).  And of course, it could
  51.  depend on what the other transaction was.  If it was a deposit,
  52.  there might be no need to alert the customer before permitting the
  53.  transaction to be retried (in which case, it would probably succeed).
  54.  
  55.  I am not suggesting that OCC is a good thing to use in high-volume
  56.  OLTP apps.  In fact, my investigation shows the literature uniformly
  57.  stating that OCC is best used in query-intensive low-volume OLTP apps. 
  58.  
  59.  Jon Rosen
  60.