Re: X/Open DTP XA Questions

In Article 18943 of comp.databases: (Chris A. Hopen) says:
>Subject: X/Open DTP XA Questions
>
>Hello DB folks,
>

 stuff deleted.
>

In Article 24239 of comp.databases: (Keith Pratt/Don Russell) say:
>>Subject: X/Open DTP XA Questions
>>
>>Hello DB folks,
>>
>>stuff deleted.
>>
>>This is called tightly coupled threads. They can work like
>>this:
>>more stuff deleted

I thought I'd add the perspective of a DBMS/RM vendor. I work in the Database Product Unit at the ASK Group Inc. We just announced the OpenINGRES/DTP family of [optional] products for integration of the OpenINGRES Database and Connectivity products w/various Open TP monitors. Initial product offerings are:

OpenINGRES/DTP for CICS    (on IBM RS6Ks)
OpenINGRES/DTP for TUXEDO  (on IBM RS6Ks)
OpenINGRES/DTP for ENCINA  (on HP9000s)

[Additional Open TP Monitors and platforms will be supported based on customer needs and/or OEM needs for specific sales situations. We are certainly glad that the NCR TOP END folks are providing the INGRES 6.4-based and the OpenINGRES Release 1.0-based XA veneer]

>In the X/A spec, the RM requirements state that:
>
>"A single instance of an RM must allow multiple threads
>logically to gain access to it on behalf of the same
>transaction branch."
>Ref: (Page 66, Calling Protocol, XA Spec)

My take would be that this particular "tweak" of the verbiage in the XA spec has more to do w/the way the TUXEDO Open TP monitor does "global transaction branch" commitment, than with the whole X/Open XA notions of "tightly and loosely coupled threads".

All of the Open TP monitors of interest to this discussion (IBM CICS/6000, TUXEDO, Encina, TOP END) require a "3-tier" process model for Open TP applications, i.e.

• Application Clients (AC)
• Application Servers (AS)
• Resource Managers (including DBMS Servers)

Keith/Don's description of how GTrid/Bqual's are generated and flow from the AC (or, if the "global transaction is really initiated at an AS, then from a *specific* AS) to one or more ASs applies to how things work in CICS/6000, Encina and TOP END. In these three Open TP products, the TP Monitor "completes" all the work for a *specific global transaction branch* from within the *same AS process* i.e. the DBMS side of the XA interface receives *all* of the XA calls for a specific *XID* from within a *single* AS process.

The TUXEDO architecture, on the other hand has *separate processes*, called the TMS (or transaction manager server) processes, that deliver the XA 2PC calls (i.e. xa_prepare/xa_commit/xa_rollback) to the DBMS/RM for a specific transaction branch, while the actual "work" for that XID is done through the AS processes (in TUXEDO, the TUXEDO servers in that "server group"). Thus the DBMS/RM receives all the *other* xa calls for this XID from the AS processes, prior to the transaction branch completion.

Implications for DBMS/RM vendors: We end up having to deal with both of these scenarios. It would have been nice if all the Open TP products worked the same, but they don't ! And each TP vendor will of course have ample justfication for *why* they built their product the way that they did build it !

p.s. We do have a lot of interest for our OpenINGRES/DTP for TUXEDO product. I was merely pointing out technical differences that have probably driven the XA standard, up above.

>>Yes. Shared memory or something needs to be used to keep
>>track of concurrent activity. However, it is more normal for
>>the client and servers to be accessing different DBMSs. If
>>they were accessing the same RM, why would one use multiple
>>APs and communication overhead? I am not aware of TM products
>>using "tightly-coupled" threads.

On the points that Keith/Don have made here:

1. We have a number of customers who have started "prototyping" large-scale Open TP applications. Production configuration expected to be 1000's of ACs and a few hundred ASs, as well as DBMSs. Interesting enough, key concerns are less to do w/heterogenous 2PC (across say OpenINGRES databases and Oracle7), and more to do w/integration of mainframe data sources (VSAM, DB2, DL/1).
2. Customers we deal with seem to *not* want to place all their data in a single OpenINGRES installation (on a single high-end machine.) Thus, there is "partitioning" of data into multiple relational tables in multiple OpenINGRES databases. The AS functions, or services are written to tie the data together, from the AC's standpoint. This is a different approach to solving VLDB and parallel DB issues, than looking for all of those features in the DBMS per se. We found this quite interesting, when we first heard about it !
3. Keith/Don have a good point about "same RM, why use multiple APs and have a communication overhead" ! We thought about this early in our design cycle, talked to some customers and have implemented the following feature in our OpenINGRES/DTP products:
   • the ability to *bind* to *multiple* OpenINGRES databases from the same application server (AS) instance. Both CICS/6000 and ENCINA support multiple open_strings (== RM instances, or "databases") per application server. Thus the programmer could define two open strings:

     "INGRES <db1> AS INVENTORY"
     "INGRES <vnode::db2> AS TICKETING"

     The actual functions/services registered with the TP system could
     then be written as follows:

     check_Inventory(.......)   <--- invoked from an AC/AS
     {

        EXEC SQL SET CONNECTION 'INVENTORY';

        [peform SQL work against db1]

        EXEC SQL SET CONNECTION 'TICKETING';

        [perform SQL work against db2]
     
      }

      I'm leaving out specific TP monitor APIs, communication
      paradigms, et.

     - you will find some other XA implementations out there that will
       require *two* ASs for doing the same amount of processing, thus
       resulting in both communication and 2PC overhead.

     - Notice that we're using ANSL SQL syntax to "switch" between the
       RMIs.

>
> 4. Are there many, if any, DBMS's that support
> such a facility?
 

>>I doubt it. RM vendors will have to comment.

I'm not sure what the thrust of the original question is, but if it's whether we "rebind" to a previously created context, for multiple requests received for the same RMI, for a specific global transaction branch, then the answer is, absolutely *YES*. In fact, we also "pool" connections to the back-end DBMS process, to optimize on connects initiated through AS processes, for multiple transactions.

> 3. Are there any DB vendors that are XA compliant?

Hope I answered your questions on where we (the ASK Group) are at this point. We also have efforts underway in the Open TP Tools area. We can discuss that under non-disclosure w/interested folks. Please contact your friendly local ASK Sales office.

>>Yes, to varying degrees. TOP END has a unique "veneer"
>>technology that puts a wrapper around non-XA RMs and "old" XA
>>RMs (old preliminary XA spec.).

BTW, the OpenINGRES/DTP products support the "Full" X/Open CAE Spec (Dec'91). We have kicked off an "Early Field Test" program at this point, to obtain feedback from select customers and TP vendors. Again, we can discuss beta/FCS availability, additional platform availability etc w/interested parties, thru your local ASK office.

There are some key issues w/prelim spec RM-XA implementations. e.g.

• the entire XID does n't make it's way to the back-end thru the TM/RM XA interfaces.
• xa_recover() is compromised. There are some risks using prelim-XA products in a production configuration. They would be just fine for prototyping applications, though.

If you're interested in a "data sheet" on our OpenINGRES/DTP products, please contact ASK North America - Telesales Group (510/769-1400).

Regards,

Mani Subramanyam

Product Manager -
  Enterprise TP Products
The ASK Group Inc -
  Database Product Unit

mani_at_ingres.com
510/748-2770 (fax)
510/748-2457 (ph) Received on Sun Nov 21 1993 - 02:44:51 CET