Transaction Processing

[George M. Sipe]

In article <3371 at sun.uucp> jr at sun.UUCP (John Reed) writes:
>In article <1692 at brl-smoke.ARPA> larry at jpl-vlsi.arpa writes:
>>"Unix is terrible for transaction processing and DP processing by banks and 
>>insurance companies."
>>I've heard this before.  Why is this so?  And does putting a U**x on top
>>an OS that does do good transaction processing solve the problem?  Would a 
>>native Unix with a kernel optimized for TP fall down on program-development
>>functions?
>
>Tolerant Systems in San Jose has a Unix TP box ready to go.  Based on
>4.2BSD Unix and multiple National Semi 32 bit CPUs.  Latest release is
>fully fault tolerant and provides data integretity across a set of
>distributed systems.  The kernel is called TX (Transaction Executive)
>and it contains LOTS more than just 4.2.
>
>Maybe somebody at Tolerant could post some more details?

Tolerant does indeed have a true transaction processing Unix.  To be
suitable for OLTP applications, an operating system must have high
transaction processing throughput and guarantee data integrity to the
user's notion of a transaction.  We also believe that because of the
nature of OLTP environments, the system should be highly available (all
the time is nice) and expandable without disruption (through extension,
while on line would do fine).  TX provides those services and much
more, WITHOUT sacrificing the Unix environment (which is 4.2, extended
to meet the SVID).

As it 'comes out of the box', Unix lacks TP features.  That is not to
say that it can't be an excellent base for extension.  As a new TP
vendor, we had the option to go proprietary or go with Unix.  Having
decided on Unix, we then could either (1) 'tack' on the necessary
facilities as daemons with appropriate kernel hacks, (2) extend the
kernel with dozens of new calls to support the environment and add
utilities as required to support that, or (3) extend the kernel in such
a way that the facilities are transparently present.  We bit the bullet
and went for door number (3).  That gives us (as far as I am aware),
the only TP operating system true to the Unix environment.

Systems implemented via approaches (1) and (2) are not really Unix...
portability is lost and the environment is alien.  Additionally, both
are frequently rich in limitations such as restricting the application
to a single database access method while at the same time requiring its
use, restricting the scope of application design to simple customer /
server pairs (vs. TX where customer processes connect via IPC to
multiple servers who in turn may further connect to multiple servers -
all maintained transparently as a single transaction).  Approach (1)
further suffers from poor performance.

Unix when implemented in conjunction with something else is ineffective
for varying reasons.  If it is a virtual machine or parallel OS
approach you will still have most of the same problems that are present
in native ports (for TP processing, at least on the Unix side).  This
is about the same as having two different systems - and about as
useful.  Unix implemented as an emulator on top of some other
proprietary OS characteristically suffers from performance problems and
incompatible side effects.  (I know one major TP vendor who is pleased
to have cut the fork() time in half in their latest release - it's now
only 2,000 ms.)  Experienced Unix users find this unacceptable
(inexperienced Unix users don't know any better :).

In fairness to the net, I won't detail the features of TX here.  If you
are interested in learning more send me you name, address, and phone
number.  I'll have our marketing department send you appropriate
literature.  If you have specific comments or questions, I'd be happy
to reply or answer.

Disclaimer:	I am an employee of Tolerant Systems.  My views must be
		biased.
-- 
UUCP:	...akgua!rebel!george
	...{hplabs,ihnp4,seismo}!gatech!{akgua}!rebel!george
Phone:	(404) 662-1533
Snail:	Tolerant Systems, 6961 Peachtree Industrial, Norcross, GA  30071