home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / 8492 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.4 KB  |  72 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!think.com!linus!progress!gus
  3. From: gus@progress.COM (Gus Bjorklund)
  4. Subject: Re: Oracle and discrete transactions
  5. Message-ID: <1992Dec15.131240.13670@progress.com>
  6. Keywords: tpc, transcations, benchmark, Oracle
  7. Sender: usenet@progress.com (Mr. Usenet)
  8. Nntp-Posting-Host: iceland
  9. Organization: Progress Software Corp.
  10. References: <1514@uniware.dk>
  11. Distribution: comp
  12. Date: Tue, 15 Dec 1992 13:12:40 GMT
  13. Lines: 57
  14.  
  15. oles@uniware.dk (Ole Skanning) writes:
  16.  
  17. >I've heard that Oracle has implemented somthing called 'discrete transactions',
  18. > in version 7, which are supposed to give better tpc-ratings.
  19.  
  20. >Could someone send me a brief explanation of what a discrete transaction is and
  21. >how it is implemented. What user benefits should there be ?
  22.  
  23. Oracle's "Discrete Transactions" is similar to a mechanism called
  24. "Field Calls" in IMS. They are useful for short update transactions
  25. that access a small number of rows.
  26.  
  27. The basic idea is this:
  28.  
  29. During forward processing of the transaction, data updated by the
  30. transaction are locked and the updates are deferred by spooling
  31. log records to a private, in memory log buffer. When the transaction
  32. commits, the updates are applied by processing the log records which
  33. are also written to the redo log. Then the locks are released.
  34.  
  35. The main goals are to minimize lock duration and the number of
  36. instructions executed.
  37.  
  38. Some advantages:
  39.  
  40. No undo information has to be generated or written to the log.
  41. If the transaction rolls back, all you have to do is throw away
  42. the spooled log records and release the locks.
  43.  
  44. Discrete transactions are short and fast, so high concurrency is
  45. possible.
  46.  
  47. Some disadvantages:
  48.  
  49. The transaction can't see its updates because they are not performed
  50. until commit time. If the transaction attempts to access the same row
  51. twice, it will fail.
  52.  
  53. Conflicting transactions cannot achieve read consistency because 
  54. no previous versions of the rows updated by the discrete transaction
  55. are available. So the conflicting transactions have to be rolled back.
  56.  
  57. Discrete transactions cannot modify both tables involved in a
  58. referential integrity constraint. This is because the transaction
  59. cannot see its own updates.
  60.  
  61. Discrete transactions cannot be distributed.
  62.  
  63. Hard to program.
  64.  
  65.  
  66.  
  67. --
  68. Gus Bjorklund              uucp:     ...mit-eddie!progress!gus
  69. Progress Software Corp.    internet: gus@progress.com
  70. 14 Oak Park                phone:    6172804361
  71. Bedford, MA  01730         fax:      6172804095
  72.