home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6228 < prev    next >
Encoding:
Text File  |  1992-08-20  |  3.0 KB  |  65 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!destroyer!sol.ctr.columbia.edu!eff!world!edwards
  3. From: edwards@world.std.com (Jonathan Edwards)
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <BtB7Lo.26u@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <Bt6IsC.F00@world.std.com> <1992Aug19.052516.24063@anasaz> <1992Aug20.192538.17842@cbnewsl.cb.att.com>
  8. Date: Fri, 21 Aug 1992 01:17:47 GMT
  9. Lines: 54
  10.  
  11. In article <1992Aug20.192538.17842@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:
  12. [about TUXEDO...]
  13. >
  14. >Another new feature allows separately administered TUXEDO networks
  15. >to call each others services and allows transactions to span these
  16. >networks.
  17. >
  18. >This means that a bank's application, which knows how to debit your
  19. >bank account, and a stock brokerage application, which knows how to
  20. >buy shares of stock, can be linked in a distributed transaction
  21. >such that the stock purchase and the debit occur together.  Without
  22. >this capability, the stock brokerage has to generate a batch EFT
  23. >transaction to the bank that may bounce, but the stock has already
  24. >been purchased.
  25. >
  26. As an implementor of just such EFT systems, I can assure you that this
  27. would be unthinkable. Distributed transactions have the well-known effect
  28. of eroding system autonomy. If one system goes down, it can leave various
  29. locks on the other which can not be broken until the system is recovered
  30. (unless they are forcibly broken, resulting in possible inconsistent databases
  31. requiring manual resolution).
  32.  
  33. >These facilities allow for a hot standby system or network to exist
  34. >far away, with all service requests done both locally, and also queued
  35. >for processing at the backup site. (I'm talking about high level
  36. >application requests: DEBIT, RESERVE-ROOM, etc., not physical database
  37. >operations.)
  38.  
  39. Again, I must say that this is impractical. Unless the system is
  40. trivial, or is single-threaded, you can not
  41. guarantee the same application execution history for a copy of the input 
  42. stream, due to timing differences in race conditions. For example, two
  43. operators request to update the same record at the same time. One is told to
  44. try again later. You can't guarantee that the same one will lose the race
  45. upon a re-execution of the same input stream with slightly different timings.
  46.  
  47. >One thing that the other proposed schemes do not address is that of
  48. >software bugs.  Whether using locally redundant hardware, or geographically
  49. >separated backup systems, the physical updates to the databases are
  50. >still done by one piece of software.
  51. >
  52. >By architecting the backup system so that it uses a different DBMS,
  53. >or even a different implementation of the application, it is more
  54. >likely that one system will be able to continue processing if the other
  55. >is stopped by a bug.
  56.  
  57. Maybe you should think about this idea a little bit more. I'll leave it
  58. at that.
  59.  
  60. Thanks for your post never the less.
  61. It sounds like Tuxedo is alive and well, and perhaps taking on TransArc.
  62. I will have to look into it further.
  63.  
  64.  
  65.