larry@jpl-vlsi.arpa (03/11/86)
"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?
Larry @ jpl-vlsi.arparon@BRL.ARPA (Ron Natalie) (03/11/86)
I don't know why they say UNIX is bad for transaction oriented stuff, since it you transact with 2 UNIX systems every time you make an 800 long distance call. _Ron
wje@daisy.UUCP (William J. Earl) (03/15/86)
In article <1692@brl-smoke.ARPA> larry@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? UNIX is not fundamentally terrible for transaction processing. Rather, it simply lacks certain facilities which would make typical applications efficient and easily implementable. What is required is fast indexed record access (as in a good database system), atomic transactions with respect the above accesses, and good communications support, including BISYNC and X.25. A forms-control language or package would also be helpful (for handling formatted screens). It turns out that a database system which includes atomic transactions in a clever way, such as IBM's IMS FASTPATH, can provide very high transaction rates, with a declining cost per transaction as the transaction rate rises. There is nothing in UNIX which prevents the implementation of such a database system, at least on 4.2 BSD, but unless it is added to the kernel, perhaps as a simulated "character device driver", it must pay a high overhead for disk accesses. The problem is that UNIX only provides asynchronous I/O via the block cache, but a database system needs to manage its own cache. On System V, one could use shared memory, extra "I/O server" processes, and semaphores to provide asynchronous I/O at user level, but one would have not protection for the data, since it would then be visible in all applications. Putting UNIX on top of most of the transaction-oriented operating systems with which I am familier would likely lead to unsatisfactory UNIX performance. An exception would be in a virtual machine environment, as on VM/370 with MVS and UTS running in parallel virtual machines. On the other hand, such a system allows only cross-development, in that one cannot debug the application under UNIX. A UNIX with a transaction-processing kernel should certainly be feasible, but the kernel would be substantially different from a normal UNIX kernel. -- William J. Earl Daisy Systems Corporation, Mountain View, CA
jr@sun.uucp (John Reed) (03/17/86)
In article <1692@brl-smoke.ARPA> larry@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? <diclaimer - I used to work there and I am still holding my stock and hoping> JR. -- ...!{ucbvax,decwrl,ihnp4}!sun!jr (John M. Reed) Sun Microsystems Inc, 2550 Garcia Ave, MS5-40, Mountain View, CA, 94043 415-960-7336
law@pecnos.UUCP (Steve Law) (03/18/86)
> > I don't know why they say UNIX is bad for transaction oriented stuff, > since it you transact with 2 UNIX systems every time you make an 800 > long distance call. > > _Ron If you make an 800 long distance call, I think you transact with UNIX/RTR (its old name is DMERT) which is actually a different operating system although its root are from UNIX/RT and MERT. Steve Law --*-------*-------*-------*-------*-------*-------*-- Name: I. S. Law (Steve) UUCP: ihnp4!vax135!petsd!pecnos!law ARPA: vax135!petsd!pecnos!law@BERKELEY US Mail: MS 314B; Concurrent Computer Corp. 106 Apple St; Tinton Falls, NJ 07724 Phone: (201) 758-7280 --*-------*-------*-------*-------*-------*-------*--
latham@bsdpkh.UUCP (Ken Latham) (03/19/86)
In article <152@daisy.UUCP> wje@daisy.UUCP (William J. Earl) writes: >In article <1692@brl-smoke.ARPA> larry@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? > > UNIX is not fundamentally terrible for transaction processing. Rather, >it simply lacks certain facilities which would make typical applications >efficient and easily implementable. > What is required is fast indexed record >access (as in a good database system), atomic transactions with respect the >above accesses, > and good communications support, including BISYNC and X.25. WORKING on it >A forms-control language or package would also be helpful (for handling >formatted screens). YUP >There is nothing in UNIX which prevents the >implementation of such a database system, at least on 4.2 BSD, but unless >it is added to the kernel, WRONG >it must pay a high overhead for disk accesses. The problem is that UNIX only >provides asynchronous I/O via the block cache, but a database system needs >to manage its own cache. YUP > On System V, one could use shared memory, YUP again >extra "I/O server" processes, and semaphores to provide asynchronous I/O >at user level, and again > but one would have not protection for the data, WRONG We have such a DataBase system UP and Running... We're developing IT! Ken Latham I would tell you more, but it is VERY PROPRIOTORY as yet!
george@rebel.UUCP (George M. Sipe) (03/22/86)
In article <3371@sun.uucp> jr@sun.UUCP (John Reed) writes: >In article <1692@brl-smoke.ARPA> larry@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