Newsgroups: comp.databases.theory
Subject: Re: transaction processing - DBMS vs TP monitor
From: briand@anasaz (Brian Douglass)
Date: 26 Aug 92 18:38:37 GMT
Distribution: usa
Organization: Anasazi, Inc.  Phoenix, Az
Keywords: TP 2PC

In article <714785823.102962@paladin.owego.ny.us> beal@paladin.owego.ny.us (Alan Beal) writes:
>As database products have started to suport two-phase commit, an important
>questions arises as when one should use a DBMS for transaction processing
>and when one should use the facilities provided by OLTP software.  Has anyone
>written a paper providing a set of guidelines for this subject?  I would
>like to start a discussion of the pros and cons of each approach and
>arrive at a consensus as to when one approach should be used over another.
>It seems that if I want to update multiple heterogeneous databases, then
>OLTP is the way to go now.  But with a multiple homongeneous databases,
>using a DBMS to has many benefits including location transparency and
>a simpler interface (SQL statements, then COMMIT).  Here are some comparisons
>that come to mind:
>
>	 DBMS                                     OLTP
>      ----------------------------------    ----------------------------------
>Pros  Simple SQL interface                  Heterogeneous DBMS, file support
>      Location transparency                 XA interface supported by vendors
>      Possible global optimization          Load balancing
>      Transparent network support           Interface with CICS

						Increased Network access.
I know that Tuxedo typically allows 1000+ network connections to a single
system.  When Oracle obtained a TPC benchmark of over 1200 TPS, they
utilized Tuxedo to give them over 1200 sessions into the application.

>Cons  Inconsistent gateways                 More complex interface
>      No heterogeneous support              Lack of standards

I believe both of these statements to be false.  First, in the Resource
applications you typically use ESQL/C to write a transaction into the DBMS.
If you sqlca.sqlcode returns a 0, you execute a TXCOMMIT (in Tuxedo),
instead of ESQL statement of COMMIT.  The logic is the same as a DBMS
application (a bit more modular I think), just different syntax.


On standards, you have the X/Open XA standard to handle the 2PC prototocol,
and the Posix DTP work group (I forget the number) working to define
interfaace standards.  In fact, I heard a rumor recently that Tuxedos ATMI
interface was adopted by the Posix group as the standard interface between
thepplication. application and TM (anyone have facts?).

In addition, there is an archtectural difference between TMs and DDBMS.
DBMS are typically client/server in their approach.  TMs utilize a 3 level
approach of client/TM/server.  As such, there is a disconnection between
the technology to write the client and that of the server.  You could build
a client using some X-Window generator and have it talk to DBMS products on
Unix, VMS or MVS.  Also, suppose you get your application running and you
find that DBMS Z is not fast enough, after your application has gone live!
With a TM, you could take DBMS Y, and begin porting your Server process to
it it, test them, and then bring them online one by one without having to
change client software.  Done right, you should even have to take down your
application.

There is nothing wrong with a strict DDBMS approach.  However, I believe
that the by including a TM in a distributed application, the developer
gains an enormous amount of openness and flexibility to solving
problems that may arise during application development.

>-- 
>Alan Beal
>Internet: beal@paladin.Owego.NY.US
>USENET:   {uunet,uunet!bywater!scifi}!paladin!beal


-- 
"... For I have sworn upon the alter of god, eternal hostility against
every form of tyranny over the mind of man."  Thomas Jefferson
Brian Douglass		briand@anasazi.com 	602-870-3330 X657