[ZOIS] Site Home Page * Contact ZOIS * Search * Contents * Demonstrations * Blog

Mr. OLTP's Answers

At the moment everything is a bit higgledy-piggledy, I'll get around to indexing and organising this stuff properly at some point, but for now you can use this list of questions, or treat it as just one long, and hopefully, interesting narrative.

The Questions

If your question is not in the above, go ahead and ask Mr. OLTP.

The Answers

Stuart from Virginia asks: What is XA?
XA is an interface between a TPM and a Resource Manager (RM) which is used to control Transactions in which the RM is participating. The RM maintains a log of the work that it is currently involved in and tags this with a unique transaction identifier, a trid, which it passes to the TPM. The TPM itself maintains a Transaction Log, held on disk to make it durable over system crashes. XA is a standardized interface which is used to pass and coordinate the trid. Most RDBM are now XA compliant (to a greater or lesser degree) as well as an ISAM package and at least one Reliable Queue.

Vakis from Sheffield asks: What is an RM?
Often TPM people band about the term Resource Manager (or RM for short). An RM is a recoverable resource available to a TPM. The RM can participate in 2 Phase Commits usually but not necessarily through the XA interface, the standard interface for such things. The actual work between the RM and the user's program is performed by a more normal and visible interface, such as SQL.

Stuart from Liverpool asks: Can you Commit and Rollback in SQL?
It is definitely not the done thing in TPM to do Commits and Rollbacks (although I'll say there are exceptions). The SQL COMMIT and ROLLBACK are used to control Transactions in an RM in the absence of a TPM. You use the TPM's transaction defining interface to control Transactions in a TPM environment, for there may be other Resources involved in the Transaction. An example of this is CICS's EXEC CICS SYNCPOINT.

Pat from Köln asks: What's Non-XA?
Resource Managers (RM) can co-ordinate Transactions using non-XA interfaces. XA is a standard so why bother to use it. These RM tend to be associated with only one TPM (for example /Q, the Reliable Queue is only used with Tuxedo). As yet nobody has produced a `better than' XA interface but some RM producers have tried to subvert it (for example putting the interface on their TP-light product).

Andy from Stains asks: How do RMs Connect to a TPM?
They connect by using XA. The RM attaches to the TPM directly upon startup. RM specific information is passed in an XA opaque string known as the XA open string. This is where some authentication information is passed to the RM. The SQL CONNECT is forbidden in TPM environments, with one exception, DB2. DB2 (and I've only seen it in a CICS environment) uses the CONNECT statement to switch between two simultaneously connected databases.

Gordon from Boldon asks: What is a Reliable Queue?
As we've seen us OLTP-ers like to talk about RM, Resource Managers. An RM manages a resource for us, which is usually recoverable (and so can participate in Transactions). RMs are usually databases, but they need not always be Relational Database Managers. One important class of RM is the Reliable Queue. A Reliable Queue is a database where Messages are stored in an ordered sequence and can then be retrieved in that same order. You can simulate a Reliable Queue in other more generalised database managers (for example with an incremental sequence number as a key), but in practice a number of these specialised databases have evolved with TPM. They are usually very tightly coupled to each other, the Reliable Queue database not using XA, but rather a private transaction control interface. Indeed there is only two Reliable Queue databases which have an XA interface (to Mr OLTP's knowledge). IBM's MQ Series is available on a large number of Open and non-Open systems and Microsoft have MS Message Queue Server (MSMQS), also known as Viper, available currently only Windows NT.

Reliable Queues generally have a specialised queue oriented isolation policy. They are usually used where asynchronous processing is desired and as an interface between loosely coupled Transactional systems. A message from one system is placed on a Reliable Queue and Committed (as part of some other Transaction). The message is then recovered and deleted by a second system, again as part of a larger Transaction. Some Reliable Queues can have their data addressed randomly and some can act as a First In First Out system, rather than a Last In First Out. Such Reliable Queues, Mr. OLTP suggests, can be considered Reliable Stacks.

Ed from Richmond asks: Which is the best TPM?
The stock weedy answer. It would be imprudent to discuss the merits or dismerits of a particular TPM without knowing fully what particular job it was being tasked for.

Ed from Richmond asks: What's a Transactional Model?
It is fair to point out that TPM are different although they address much the same goals and market place. There are major differences in how they organise their Transactions.

CICS, the oldest of the TPM that you'll find discussed on this site uses a chained model. That is you are always in a Transaction even if you are doing no specific recoverable work. Issuing the CICS Transactional boundary statement, EXEC CICS SYNCPOINT, causes you to complete one Transaction and start another.

Tuxedo and Top End, however, have a bracketed model. These TPM allow you to be outside a Transaction and start one specifically with for example tx_begin. Similarly tx_commit completes the transaction, and normally, a new one will not begin until a tx_begin has been issued. While you are in a Transaction, you are forbidden to issue another tx_begin, for the Transactional model they use is also flat.

Encina takes this even further with its idea of Nested Transaction, touched on in the Transactions page elsewhere on the site. In Encina's Trans-C transaction can be issued several times producing both nested and discrete Transactions. Completing the inner one does not necessarily complete the outer one, while completing the outer one will complete all the sub-Transactions contained within it.

Stefan from Randers asks: What is DCE?
DCE (Distributed Computing Environment) is a technology which is an amalgam of several elements. The core of DCE is Apollo's NCS RPCS. These RPCs are considered to be more sophisticated and easier to program than the more widespread Sun or ONC RPCs. Around this RPC core there is the Kerberos authentication mechanism, DEC's directory and name service, a secure distributed time keeping service and Mach Operating System like lightweight threads. DCE is the technological base of the Encina Tool Kit (ETK) on which a number of TPM are based, Encina itself, ACMSxp, and a variety of CICS.

Microsoft's RPC's DCOM, are based on DCE and they are compatible to a certain extent. DCOM is the basis of Viper (or MTS), Microsoft's TPM.

There is, of course more about DCE in the DCE FAQ (Frequently Asked Questions, with answers).

Tom from Beckermet asks: What is RPC?
Remote Procedure Calls (RPC) are a paradigm of programming in distributed applications. A program can be broken down into a number of discreet components can have well formed interfaces. These components are known as sub-programs, sub-routines, functions or procedures, depending upon who you talk to and what programming language that you are using. These components (we'll call them procedures) can be distributed, the invoking program can exist either locally or on some other machine.

There are two major varieties of RPC. That which has its origin with Apollo computer (now part of HP), the other that from SUN. Sun's RPC (known as Open Network Computing or ONC RPCs) are more wide spread, forming the basis on the Network File System, NFS. It is, however, the Apollo ones (known as Network Computer Services (NCS) RPCs) which are the most interesting in a Transactional context because they form the basis for DCE and thence a number of TPM.

Sorry about "paradigm", it had to appear somewhere on this site!

Barry from Whitehaven asks: What is IDL?
RPC's require their interfaces to be somewhat more tightly defined than those of their local cousins. For example a string type, conventionally, in the language `C' and its successors is a pointer to an array of char, the last element of which is zero. In a local procedure call only the pointer is passed and the `string' stays where it is in memory. When moving the `string' to another machine and process, possibly to a program written in another language, something more thorough and rigorous is required. An Interface Definition Language (IDL) does this job. An interface, written in an IDL, is usually compiled into stubs or fragments in a target language such as C. These fragments, which pack and unpack the data from an RPC protocol unit are then incorporated into programs (which of course, can be, in the case of DCE's RPC, made Transactional).

Hiroki from Tokyo asks: Can I use a debugger on my TPM programs?
Mr. OLTP believes that symbolic debuggers (such as gdb(1)) are powerful aids to the debugging of user programs. Their use in TPM environments (to debug the user programs running in Servers, Processing Agents or Application Servers) can cut delivery time on these programs and make them a good deal more reliable. There are one or two caveats that must be observed however, for the use of a symbolic debugger in these circumstances requires a very good understanding of how a TPM works under the covers and the likely side effects of stopping time critical interdependent processes.

The use of a symbolic debugger requires a knowledge of the internals of a TPM and the architecture of the surrounding systems. A symbolic debugger can cause processes to stop. They thus can appear to have failed to other processes in the TPM system. This is part of the nature of the use of a symbolic debugger. Stopping such processes will thus possibly cause the appearance of spurious Deadlock failures, instances of Heuristic Completion, client timeouts and failures in Transaction integrity. In addition you may get other processes failing because of mutex, file lock, and Transaction communication problems. Since the TPM system will act to mitigate what, in a normal situation, is considered a major failure you may also see unexpected Transaction rollbacks, spurious restarts of processes under debugging and in certain circumstances the complete stop of a TPM environment.

Having read and inwardly digested the above, here is what you do.

The program you are to debug should be compiled with the option which will incorporate symbolic debugging information, it is the -g option on the C compiler on most systems, cc(1). The program is then incorporated into the TPM system in the normal way. Inform the TPM to start only one server process for the program and start the environment. Once things are in place you can attach the symbolic debugger of your choice and tell it to break at an appropriate place. Send a message to the TPM environment that will activate your program and off you go. Remember when you quit your symbolic debugger session to detach the symbolic debugger first, allowing the TPM to clean up whatever debris that is left.

As you have read the caveats there should be no need to underline the need to tell people working in the same TPM environment as you what you are doing (if you want to stay friends). Further, you are strongly advised never to use a symbolic debugger in a production environment (if you want to stay employed).

Keith from Southampton asks: What is Heuristic Completion?
While we always strive to have a TPM commit or rollback Transactions it is sometimes necessary for an RM to do this independently. When this happens it is known as a Heuristic Completion. In a modern TP System it is normal to assume failure and the majority of heuristic completions are of this type, being premature rollbacks. When they occur, they are usually reported at the prepare or voting phase of a transaction. Heuristic completions such as these pose no threat to transaction integrity since the rest of the participants can be rolled back too. Danger only occurs if a heuristic commit is encountered. The work on that particular RM is now in stable storage and cannot be undone should another participating RM vote for a rollback of the entire Transaction.

Bob from Winchester asks: What is TP-light?
Although this site is largely devoted to the use of Transaction Processing Monitors on UNIX, the majority of transactions in distributed UNIX TP systems are not actually handled by the TPM described in the pages found here. Most Transactions are coordinated by TP products closely associated with a Database Manager. These TPM like programs, which are proprietary, are used to provide Transactional control to several instances of the same Database and are often involved in technology such as replication, in which two or more databases are maintained in parallel. The scope of these products, although they scale well in the medium range with the Database they are designed to work with, is poor. Not surprisingly they provide poor integration to competing vendors' Databases. Although they will have gateways to mainframe Databases and TPM, they generally will not participate in a Two Phase Commit with them.

Some RDB vendors, notably Oracle, muddy the waters by putting their XA interface on their TP light product, forcing additional software if full Transaction Processing solutions is required or desired.

Marc-Antoine from Brussels asks: What is a Container
As with any new technology a new jargon has to be supported. This is valid for Enterprise Java Beans (EJB) as any other. The components that surround an EJB are styled the Container. We can thus use sentences like "The Container manages network connections on behalf of the EJB" and so forth.

Gui from Charleroi asks: What is a Contract
As with Container this is a newish (but heavily overloaded) EJB jargon word. The Contract is the relationship between the EJB and the Container and the relationship between individual EJBs themselves.

Vincent from London asks: Why is ZOIS called ZOIS?
Mr. OLTP is very old and originally wrote programs on Coding Sheets, remember them? There seemed to be several different conflicting standards to be adhered to (so nothing's changed there then). In order to get his zeros and letter 'O's the right way around (as well as some other letter/number combinations) Mr. OLTP started writing "ZOIS are letters and 2015 are numbers" on the top of each sheet. What a perfectly splendid name for a company (and later DNS domain &c. &c). The numbers and letters still got punched the wrong way around, though.

If you thought ZOIS is a unique name a quick Alta Vista search reveals a large number of hits. It transpires that Zois is a family name, originally from Slovenia or there abouts. There's even a rock called "Zoisite". Feedback from folks called Zois has also revealed that `Zois' is Greek for life in the genative case. Perhaps Mr. OLTP should have hired a Branding consultant after all.

Heather from Hursley asks: Why do you drink so much coffee on Monday?
[Picture:  Coffee Beans]
Caffeine keeps you going
Coffee contains Caffeine, a chemical which belongs to a group of compounds known as methyl-Xanthines, all of which have a similar pharmacological action, that of keeping you awake and alert. This important property has been studied by a number of eminent scientists and is well characterised. Caffeine acts as an inhibitor of an important biochemical catalyst or enzyme known as phosphate-diesterase. This enzyme breaks down cyclic Adenosine Monophosphate (cAMP) an internal cell messenger for a number of hormones including Adrenaline (also known as Epinephrine). By stopping the break down of cAMP its level within the cell is maintained at an artificially high level keeping you bright, alert and ready for those difficult OLTP questions.

Go ahead and ask Mr. OLTP a question.

~Z~


Date: 1999/06/28 09:33:02


Break Frame * E-mail Webmaster * Author * Copyright