Re: X/Open XA Standard and Oracle

NOTE: Before you read any further, look at this. My prior posting seems to

	have caused a little bit of a stir in some quarters.  Please, mellow
	out!  I am not and will not bash Oracle Corp. or any of its employees.
	This is just an informed viewpoint on TP monitors and XA.  These 
	issues do not get talked about enough -- in this newsgroup or any
	other.  Please let us bounce ideas off each other without getting
	your shorts in a knot!  I'm not offended by what Sandor wrote, and I
	hope most others are not by my response, but it's ultimately up to
	you; I'm not here to argue.

Sandor Nieuwenhuijs (snieuwen_at_nl.oracle.com) wrote:

: This might be an interesting subject. To my humble opinion, there are only
: two situations where a TPM in a Unix environment might be useful:
 

: 1. If you want to migrate existing (TP monitor based) 3GL applications off
: a Mainframe and run it without to many dramatic changes.

Yes, TP Monitors do make good down-sizing (or "Right-sizing") tools for legacy applications. IBM has CICS/6000 for its RS/6000 line.

: 2. If you want to integrate multiple (XA-compliant) databases in one
: transaction.

ABSOLUTELY. In my humble opinion, this is the best way to use heterogenous databases. However, this need not only be heterogenous in one transaction (i.e.- transfer data from Oracle to Informix in one atomic transaction).

TP monitors are useful for more than just these two, though...

TP monitors give the client application writer the ability to seamlessly, opaquely integrate multiple databases (or other resources) into a single call interface. For example, you could have a service called BALANCE_INQUIRY which the client side could call. Based on the account number, the TP monitor can route that query to an Oracle DB in Houston or an Informix DB in LA. The application doesn't need to know where the data resides -- or in what brand database. The TP monitor takes care of this through data-dependent routing. Can Oracle do that alone??

: I have had a glimpse of a DataPro report which claims exactly the same.
: A *LOT* of the functionality of a TPM is already in modern databases like
: Oracle7.

*SOME* of the TP monitor functionaly is finally implemented in DBs like Oracle. (e.g. - distributed databases, 2PC, Stored Procs, Naming, etc...) These features have been available for years in TP monitors.

: The big disadvantage I personally see of using a TPM is the fact
: that you can hardly use a proper 4GL anymore, you have to go back to the
: ages of writing zillions of lines of C or Cobol.

I think you are mistaken here. You can use any 4GL which can call C functions/COBOL programs. Additionally, Unisys' Windows OLTP product lets you use DDE as a call mechanism, so you can use it from, Excel, for example. (This is NOT an ad, just an example of various ways to call TP monitors) I've also used Informix 4GL and Informix TP Toolkit to build servers. 4GLs do talk to TP monitors.

: It is also virtually impossible to do some form of ad-hoc querying, every
: database access has to be pre-programmed.

High volume, OnLine Transaction Processing usually doesn't use ad-hoc queries. That's more for an Executive Information or Decision Support System. TP monitors usually don't claim to be ad-hoc query tools. If they do, they're really pushing the envelope of their use (perhaps too far). (Although you could write a server which would handle ad-hoc queries, trust me...)

: This is not to do some TPM-"bashing". I am seriously interested in the
: opinions and discussions of users about this subject. I am pretty sure
: there are good purposes for a TPM (I just haven't found enough).

Additionally, this followup is _NOT_, repeat, NOT an Oracle bash. I merely wish to point out that an Oracle-only solution is not best suited for ALL applications. There are things that other software pieces do better, that's all.

A few other advantages TP monitors have over a straight DB solution (not just Oracle...):

Application Framework: With DB only solution, SQL is usually where the

      application structure comes from.  SQL is (usually) only capable of 
      managing local transactions or relational data.   SQL, alone can't
	- Load balance application processing loads
	- Prioritize application traffic
	- Reduce network traffic through function shipping vs. data shipping

SQL-parsing:  Many DB-only solutions submit SQL to the vendor's proprietary
      network transport, which parses and interprets the SQL, then passes 
      that across the wire to the appropriate machine.  Then the DB must 
      parse and interpret the SQL message at the server side.  This can be a
      real performance hit.  

      TP monitors keep the precompiled SQL servers on the same machine as the
      database.  The client merely calls the service with the appropriate
      data.  The TPM knows where to send the request, it doesn't have to
      parse each query.  This reduces the amount of traffic going over the 
      wire.

Application Flexibility:  In a DB-only solution, you cannot take advantage of
      replicated services or data-dependent routing.  Without these, you lose
      availability and flexibility.

Non-Database Objects:  With Client/Server solutions, you may not want to access
      only RDBMSs.  Granted, Oracle provides Oracle*Mail, but why go through
      Oracle to go to Oracle*Mail to go to standard Internet mail?  Other
      resources needed may be barcode readers, printers, ISAM file systems,etc.
      A DB-only solution would have a hard time managing all these types of
      resources.

TP monitors, with or without DBs, with or without XA, make nifty client/server application building frameworks. Much of what you would have to provide (network interface, routing, function calls, administration, etc.) Are already available via such products. Perhaps the T (transaction) in TP monitors should be replaced with D (distributed). (Although the transaction paradigm offers many features for a distributed environment -- but that's another discussion altogether...)

Finally, with regard to 2-phase commit. Mr. Richter was partially correct in stating that Oracle supports 2PC with just a COMMIT statement. However, without a TP monitor and XA, all the participants in the transaction MUST be Oracle DBs. This means no other DB vendor, or e-mail system, or ATM machine, etc.

--
Brandon Ausman
Open/OLTP (that is OnLine Transaction Processing, not Oracle basher...)
Unisys, Salt Lake City

******
Remember, these are _MY_ points, and _MY_ opinions, not those of Unisys Corp.
or any of its other employees.  Let me keep this much of my work.  Everything
else I turn over to the company in a polically correct manner...