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