Path: utzoo!attcan!uunet!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!amdahl!rtech!llama!jas
From: jas@llama.rtech.UUCP (Jim Shankland)
Newsgroups: comp.databases
Subject: Re: Asynchronous SQL
Message-ID: <5030@rtech.rtech.com>
Date: 16 Mar 90 22:35:11 GMT
References: <2438@ncr-sd.SanDiego.NCR.COM> <745@dgis.dtic.dla.mil> <3510@infmx.UUCP> <779@dgis.dtic.dla.mil> <3585@infmx.UUCP> <4990@rtech.rtech.com> <793@dgis.dtic.dla.mil>
Sender: news@rtech.rtech.com
Reply-To: jas@llama.rtech.com (Jim Shankland)
Organization: The Eddie Group
Lines: 16

In article <793@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes:
>jas@llama.rtech.UUCP (Jim Shankland) writes:
>
>>... I'd rather see support for multiple sessions from a single client ...
>
>OK, you got it.  It's a feature of modern operating systems called a process.

Exactly, though there's a great deal of haggling to be done about
process "weight", IPC mechanisms, programming language issues, and
so on.  Such haggling doesn't particularly belong in comp.databases,
which is precisely my point:  intra-application parallelism is an
OS and/or general-purpose programming language issue; it has no
business cluttering up SQL.  Not that ... [never mind -- derogatory
remark about SQL deleted].

jas