bobs@ico.ISC.COM (Bob Snead) (11/12/88)
The technical Committee of /usr/group has a special interest group which
is studying the definition of transaction processing (TP) under UNIX, and
exploring what a standard in this area may look like. To date we have
constructed a discussion paper which lists what we feel are the fundamental
aspects of UNIX TP (called "axioms"). While we feel there is nothing
controversial in these axioms, we would like to solicit your feedback for
two reasons. First we would like a sanity check. Secondly we would like
to spark your interest in participating in the deliberations.
The axioms are as follows:
1. Axioms
1.1 Transactions: The ACID Rules
The fundamental definition of a transaction is given most
succinctly by the well known ACID rules. Other important
attributes of transactions, such as serializability, can be
inferred from these rules.
1.1.1 Atomic: A possibly complex set of modifications to
permanent data made are either all done or none are done.
Such a set is seen as indivisible.
1.1.2 Consistency: Permanent data are at all times con-
sistent.
1.1.3 Independent: Modifications to permanent data executed
by different transactions are independent of each other.
1.1.4 Durable: Once a change is made to permanent data it
persists.
1.2 POSIX Framework
POSIX is *THE* UNIX standard. Other standards, such as the
SVID, OSF and X/OPEN are espoused to be POSIX compliant. It
is the base, the foundation for the other standards. There-
fore the fundamental support required for UNIX TP must be a
part of POSIX. A proposed standard must adhere to the POSIX
approach and be posed in a POSIX style. POSIX is applica-
tion oriented, promoting portability of applications across
UNIX system environments. It specifies interfaces, not
implementations. The interfaces form a minimal set, each
minimally defined. And they are broadly implementable.
1.3 On-line Systems
UNIX TP is fundamentally on-line in nature. UNIX is an
interactive, time-sharing system and hence support for stan-
dard TP should focus on interactive applications. However,
a good TP system must be able to support some batch activi-
ties. As an on-line system, a UNIX TP system is in some
sense a real-time system, guaranteeing certain minimal
response times to users. In addition, a UNIX TP system must
also make certain guarantees concerning throughput, usually
given in terms of transactions per second.
1.4 Distributed Applications
UNIX TP is distributed TP. Much more often than not UNIX
machines are networked. More and more UNIX applications are
designed to utilize these networks, becoming essentially
distributed applications. TP applications, generally, are
such applications.
1.5 Multi-piece TP Systems
Complete UNIX TP systems frequently are composed of various
off-the-shelf pieces such as windowing systems, screen
handlers, file access methods, DBMSs, network software and
the like, with the TP application code acting as the glue.
Frequently these pieces come from various vendors. Fre-
quently applications need to define transactions that span
modifications to data controlled by more than one such
piece.
1.6 Heterogeneous Applications
UNIX TP is heterogeneous TP. UNIX exists in a heterogeneous
world, a world built not only of differing hardware, but
differing software as well. UNIX TP must fit into this
world. This means that a TP application may be built which
has a UNIX piece, with other pieces in other OSs.
1.7 Scalability
UNIX TP applications are scalable. A fundamental advantage
of UNIX is that it runs on a wide range of processors with a
wide range of power. An application which runs on the smal-
lest can, with minimal change, run on the largest. Simi-
larly there are computer systems that grow by adding proces-
sors to a processor complex. When a business grows it can
grow its computer resources and maintain the same applica-
tions. The TP applications must be scalable all the way up
to high end.
1.8 Availability
Because of their use (POS terminals, ATMs etc) and because
of the transaction definition, TP applications usually make
guarantees about availability. Generally these guarantees
take the form of some maximum period of unavailability dur-
ing some (hopefully!) longer span of time. This period may
include scheduled downtime.
Any feedback would be greatly appreciated. If you don't agree with any or
all of the axioms, please tell us why. If you think there should be others,
then by all means state your case. If you would like more information on
the special interest group (entitled /usr/group/tpsig) then please contact
me. Thanks!!!!
Bob Snead
Chair: /usr/group/tpsig
Interactive Systems Corp.
2950 Wilderness Place
Boulder CO, 80301
(303) 449-2870
bobs@ico.isc.com