ZOIS *
Search *
Table of Contents *
Open OLTP News
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
ZOIS called
ZOIS?
If your question is not in the above, go ahead and ask Mr. OLTP.
The Answers
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.
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.
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.
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.
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).
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!
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).
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).
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.
ZOIS called
ZOIS?
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.
|
| Caffeine keeps you going
|
Go ahead and ask Mr. OLTP a question.
Date: 1999/06/28 09:33:02