home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / theory / 447 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  4.0 KB
  1. Path: sparky!uunet!decwrl!infopiz!lupine!motcsd!udc!mcdphx!ennews!anasaz!qip!briand
  2. Newsgroups: comp.databases.theory
  3. Subject: Re: transaction processing - DBMS vs TP monitor
  4. Message-ID: <1992Aug26.183837.15241@anasaz>
  5. From: briand@anasaz (Brian Douglass)
  6. Date: 26 Aug 92 18:38:37 GMT
  7. References: <714785823.102962@paladin.owego.ny.us>
  8. Distribution: usa
  9. Organization: Anasazi, Inc.  Phoenix, Az
  10. Keywords: TP 2PC
  11. Lines: 68
  12.  
  13. In article <714785823.102962@paladin.owego.ny.us> beal@paladin.owego.ny.us (Alan Beal) writes:
  14. >As database products have started to suport two-phase commit, an important
  15. >questions arises as when one should use a DBMS for transaction processing
  16. >and when one should use the facilities provided by OLTP software.  Has anyone
  17. >written a paper providing a set of guidelines for this subject?  I would
  18. >like to start a discussion of the pros and cons of each approach and
  19. >arrive at a consensus as to when one approach should be used over another.
  20. >It seems that if I want to update multiple heterogeneous databases, then
  21. >OLTP is the way to go now.  But with a multiple homongeneous databases,
  22. >using a DBMS to has many benefits including location transparency and
  23. >a simpler interface (SQL statements, then COMMIT).  Here are some comparisons
  24. >that come to mind:
  25. >
  26. >     DBMS                                     OLTP
  27. >      ----------------------------------    ----------------------------------
  28. >Pros  Simple SQL interface                  Heterogeneous DBMS, file support
  29. >      Location transparency                 XA interface supported by vendors
  30. >      Possible global optimization          Load balancing
  31. >      Transparent network support           Interface with CICS
  32.  
  33.                         Increased Network access.
  34. I know that Tuxedo typically allows 1000+ network connections to a single
  35. system.  When Oracle obtained a TPC benchmark of over 1200 TPS, they
  36. utilized Tuxedo to give them over 1200 sessions into the application.
  37.  
  38. >Cons  Inconsistent gateways                 More complex interface
  39. >      No heterogeneous support              Lack of standards
  40.  
  41. I believe both of these statements to be false.  First, in the Resource
  42. applications you typically use ESQL/C to write a transaction into the DBMS.
  43. If you sqlca.sqlcode returns a 0, you execute a TXCOMMIT (in Tuxedo),
  44. instead of ESQL statement of COMMIT.  The logic is the same as a DBMS
  45. application (a bit more modular I think), just different syntax.
  46.  
  47.  
  48. On standards, you have the X/Open XA standard to handle the 2PC prototocol,
  49. and the Posix DTP work group (I forget the number) working to define
  50. interfaace standards.  In fact, I heard a rumor recently that Tuxedos ATMI
  51. interface was adopted by the Posix group as the standard interface between
  52. thepplication. application and TM (anyone have facts?).
  53.  
  54. In addition, there is an archtectural difference between TMs and DDBMS.
  55. DBMS are typically client/server in their approach.  TMs utilize a 3 level
  56. approach of client/TM/server.  As such, there is a disconnection between
  57. the technology to write the client and that of the server.  You could build
  58. a client using some X-Window generator and have it talk to DBMS products on
  59. Unix, VMS or MVS.  Also, suppose you get your application running and you
  60. find that DBMS Z is not fast enough, after your application has gone live!
  61. With a TM, you could take DBMS Y, and begin porting your Server process to
  62. it it, test them, and then bring them online one by one without having to
  63. change client software.  Done right, you should even have to take down your
  64. application.
  65.  
  66. There is nothing wrong with a strict DDBMS approach.  However, I believe
  67. that the by including a TM in a distributed application, the developer
  68. gains an enormous amount of openness and flexibility to solving
  69. problems that may arise during application development.
  70.  
  71. >-- 
  72. >Alan Beal
  73. >Internet: beal@paladin.Owego.NY.US
  74. >USENET:   {uunet,uunet!bywater!scifi}!paladin!beal
  75.  
  76.  
  77. -- 
  78. "... For I have sworn upon the alter of god, eternal hostility against
  79. every form of tyranny over the mind of man."  Thomas Jefferson
  80. Brian Douglass        briand@anasazi.com     602-870-3330 X657
  81.