Transaction Processing

[Ken Latham]

In article <152 at daisy.UUCP> wje at daisy.UUCP (William J. Earl) 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?
>
>    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!