Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!jarthur!elroy.jpl.nasa.gov!ames!pacbell!rtech!ws2s!cmorris
From: cmorris@ws2s.rtech.COM (Colin Morris)
Newsgroups: comp.databases
Subject: Re: Asynchronous SQL
Message-ID: <5045@rtech.rtech.com>
Date: 18 Mar 90 05:35:19 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> <5030@rtech.rtech.com>
Sender: news@rtech.rtech.com
Reply-To: cmorris@ws2s.UUCP (Colin Morris)
Organization: Ingres Corporation, Alameda CA 94501
Lines: 32

In article <5030@rtech.rtech.com> jas@llama.rtech.com (Jim Shankland) writes:
>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 exactly. Why force the applications programmer to reinvent the wheel by
requiring _him_ to use OS or programming language features to provide the
asynchronicity? If SQL itself provides an asynchronous interface, such support
can be provided by the SQL vendor, thus freeing the applications programmer
from such concerns.

Remember, also, that (i) most current programming languages are hardly bastions
of parallelism, and (ii) application level parallelism often demands a 
process-rich environment:- don't assume that all broadly used operating systems
provide such an environment. 



----
Colin Morris,                        cmorris@rtech.com
Ingres Corp.,
Alameda, California.