home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / 8567 < prev    next >
Encoding:
Internet Message Format  |  1992-12-20  |  3.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!rutgers!andromeda.rutgers.edu!holowcza
  2. From: holowcza@andromeda.rutgers.edu (Richard D Holowczak)
  3. Newsgroups: comp.databases
  4. Subject: Re: References wanted on Distributed Databases
  5. Message-ID: <Dec.17.22.49.53.1992.22812@andromeda.rutgers.edu>
  6. Date: 18 Dec 92 03:49:56 GMT
  7. References: <1992Dec10.170708.5610@cs.brown.edu> <kitchel.724014868@manta> <1992Dec11.080514.17132@cs.ruu.nl> <1992Dec11.114955.1@bigez> <Dec.15.16.02.57.1992.27495@andromeda.rutgers.edu> <1992Dec16.175436.1@bigez>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 63
  10.  
  11.  
  12. dmmatt@bigez (Mike Mattix) writes:
  13.  
  14. >In article <Dec.15.16.02.57.1992.27495@andromeda.rutgers.edu>, holowcza@andromeda.rutgers.edu (Richard D Holowczak) writes:
  15. >> 
  16. >>   I think there is a big difference between distributed partitioned data and
  17. >> distributed replicated data.  I would be interested to know how Rdb (and
  18. >> others) handle site failures, communication failures and recovery.
  19. >> Any comments?
  20. >> 
  21. >> 
  22. >> 
  23. >> Rich Holowczak
  24. >> Rutgers University
  25. >> holowcza@andromeda.rutgers.edu
  26.  
  27. >  Since I brought up Rdb (I just get sick of hearing about the NEW ADVANCED
  28. >features of Oracle/Ingres), I probably should take a stab at this.  The 
  29. >application we did originally had distributed partitioned data (multiple 
  30. >table of different data on different network nodes).  The application 
  31.            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  32.  
  33. O.K.  This can be (and is being) done by many vendors. As to who did it
  34. first, I have no idea.   The problem with performance you state is 
  35. remedied by replicating data.  The goal (via, say one-copy token approach)
  36. is to dynamically move the data close to the people who need it while
  37. still allowing access from all others who might.  This is a tricky bit
  38. of business which I don't think Rdb or others is up to. 
  39.  
  40. The new Sybase release is supposed to handle this although not very
  41. gracefully from a theoretcal standpoint.
  42.  
  43.  
  44. >worked fine we ended
  45. >up consolidating the application on one node for performance reasons.  I don't 
  46. >believe many people will argue that distributed applications tend to 
  47. >perform worse
  48. >than applications where all the data resides on one node.
  49.  
  50.    See above. 
  51.  
  52. >The failure of a node is 
  53. >handled by the two phase commit function during a transaction.  
  54. >The failure of a node 
  55. >is handled by error trapping after that, ie the application will not be able to 
  56. >regards,
  57.  
  58. >-- 
  59. >Mike Mattix
  60. >Agricultural Group of Monsanto
  61. >P.O. Box 174
  62. >Luling, LA 70070
  63. >INTERNET Address: dmmatt@bigez.monsanto.com
  64.  
  65. ---
  66. [1mRich Holowczak[m               holowcza@andromeda.rutgers.edu
  67. Rutgers University
  68. Ph.D. Computers and Information Systems Program
  69. "Availability of Distributed Databases During Network Partitioning"
  70. +---------------------------------------------------+---------------+
  71. | The .sig, the whole .sig and nothing but the .sig | Ask about the |
  72. |           <<< This space for rent >>>             | car alarm FAQ |
  73. +---------------------------------------------------+---------------+
  74.