home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6333 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  4.5 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!cmcl2!psinntp!psinntp!ibism!gjb
  2. From: gjb@fig.citib.com (Greg Brail)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <1992Aug25.201150.22996@fig.citib.com>
  6. Date: 25 Aug 92 20:11:50 GMT
  7. References: <1992Aug19.052516.24063@anasaz> <1992Aug20.192538.17842@cbnewsl.cb.att.com> <BtB7Lo.26u@world.std.com>
  8. Sender: news@fig.citib.com
  9. Organization: Citibank IBISM
  10. Lines: 75
  11.  
  12. In article <BtB7Lo.26u@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
  13. >In article <1992Aug20.192538.17842@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:
  14. >>This means that a bank's application, which knows how to debit your
  15. >>bank account, and a stock brokerage application, which knows how to
  16. >>buy shares of stock, can be linked in a distributed transaction
  17. >>such that the stock purchase and the debit occur together.  Without
  18. >>this capability, the stock brokerage has to generate a batch EFT
  19. >>transaction to the bank that may bounce, but the stock has already
  20. >>been purchased.
  21. >>
  22. >As an implementor of just such EFT systems, I can assure you that this
  23. >would be unthinkable. Distributed transactions have the well-known effect
  24. >of eroding system autonomy. If one system goes down, it can leave various
  25. >locks on the other which can not be broken until the system is recovered
  26. >(unless they are forcibly broken, resulting in possible inconsistent databases
  27. >requiring manual resolution).
  28.  
  29. There may well be philosophical aspects to "system autonomy" that make
  30. it a good thing, but distributed transactions as implemented by Tuxedo
  31. or Encina do not cause the problems you describe above. If, for argument's
  32. sake, we describe a "physical transaction" as an atomic action managed
  33. by the transaction management system, then we will begin the physical
  34. transaction, debit the account, and send a message asking the brokerage
  35. application to purchase the stock. We wait for the brokerage to respond --
  36. if something goes wrong, we abort the whole transaction and the bank
  37. debit (along with whatever may have happened of the stock purchase) are
  38. completely undone. No locks need be forcibly broken.
  39.  
  40. Such systems as Tuxedo and Encina can implement a distributed system this
  41. way. As Mr. Orshan describes, the alternative is to send an asyncronous
  42. message to the brokerage and write enough recovery logic into the
  43. bank application so it can roll back the work when the brokerage
  44. transaction fails.
  45.  
  46. Of course, a complete financial transaction (such as an EFT transfer)
  47. may well encompass several physical transactions. In this case, the
  48. application still must be able to undo any failed step, but there are
  49. fewer steps to keep track of.
  50.  
  51. >>These facilities allow for a hot standby system or network to exist
  52. >>far away, with all service requests done both locally, and also queued
  53. >>for processing at the backup site. (I'm talking about high level
  54. >>application requests: DEBIT, RESERVE-ROOM, etc., not physical database
  55. >>operations.)
  56.  
  57. Again, doing this by placing items in a queue makes recovery more
  58. difficult than using synchronous RPCs, although it's still doable.
  59.  
  60. >Again, I must say that this is impractical. Unless the system is
  61. >trivial, or is single-threaded, you can not
  62. >guarantee the same application execution history for a copy of the input 
  63. >stream, due to timing differences in race conditions.
  64.  
  65. If you can update all the copies of the database in one atomic, physical
  66. transaction, timing differences don't matter. That's why databases have
  67. things like two-phase locking.
  68.  
  69. >>By architecting the backup system so that it uses a different DBMS,
  70. >>or even a different implementation of the application, it is more
  71. >>likely that one system will be able to continue processing if the other
  72. >>is stopped by a bug.
  73.  
  74. This is certainly possible using existing distributed transaction processing
  75. systems, and is certainly a good idea. Also keep in mind that some types
  76. of storage systems are better at some tasks than others. An ISAM-like file
  77. system may outperform a relational database for random access lookups,
  78. but will not necessarily support ad-hoc queries via SQL. So one can use the
  79. ISAM files for most day-to-day operations, and the RDBMS as a backup.
  80.  
  81.                 greg
  82. -- 
  83. Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
  84. lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the 
  85. deprivation of, as by negligence or accident. 2. To be unable to maintain,
  86. sustain, or keep. 3. The most commonly misspelled word on Usenet.
  87.