Transaction Processing
Ken Latham
latham at bsdpkh.UUCP
Wed Mar 19 07:50:50 AEST 1986
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!
More information about the Comp.unix
mailing list