Re: Preemptive Multitasking for Windows Clients via SQL*Net V1.X

From: Lawrence James <James.Lawrence_at_epamail.epa.gov>
Date: Wed, 23 Nov 1994 09:41:59 GMT
Message-ID: <James.Lawrence.19.0009B36B_at_epamail.epa.gov>


In article <39m4em$dma_at_ixnews1.ix.netcom.com> chuckh_at_ix.netcom.com (Chuck Hamilton) writes:
>From: chuckh_at_ix.netcom.com (Chuck Hamilton)
>Subject: Re: Preemptive Multitasking for Windows Clients via SQL*Net V1.X
>Date: 7 Nov 1994 20:59:02 GMT
 

>In <783941593_at_f573.n115.z1.ftn> Michael Stowe
><Michael.Stowe_at_f573.n115.z1.fidonet.org> writes:
 

>>
>>*** Quoting Wong_at_Interlog.Com to All dated 11-01-94 ***
>>> Does anyone know in SQL*Net v1.x if there is a way to eliminate the
>>> Windows lockup when a long query or stored procedure is executed from
 a
>>> Windows client applications against an Oracle RDBMS?
>>
>>Windows is not a pre-emptive multitasking platform, as you have already
>>mentioned, so don't expect miracles. But that is really only part of
 the issue
>>-- SQL*Net is synchronous, which means that it must wait for a reply
 from the
>>server (on any platform) so the current application will not be able
>>to process anything else, anyway.
>>
>>The basic "lockup" you experience under Windows is because the Windows
 message
>>queue is not being polled; to prevent it, Oracle would have to a) use
>>asynchronous SQL*Net and b) poll the message queue while SQL*Net is
 waiting for
>>a reply.
>>
>>
 

>Interesting.
 

>I'm considering Oracle for a data warehouse and was told by the Oracle
>rep that "you don't have to wait for your query to finish before
>switching to another task (word processing, spreadsheet, etc.) and
>continue being productive". I haven't seen the product demoed yet
>though. I'm just going on what he told me. Are you saying that this
>salesmen lied? (Gee imagine a dishonest salesman... or politician for
>that matter). He even went as far as to get one of the techies on the
>line and confirm this for me! The query tool he as talking about was
>Browser (Oracle's own tool).
 

>There are applications that'll do the message queue polling for you.
>Forest and Trees is one of them. I've used it with an ODBC driver (not
>for Oracle) that does not poll the message queue, but by selecting F&T's
>"spin a leaf" option, was able to continue working in other applications
>while a long query was in progress.
 

>I'm looking for an ad-hoc query/reporting tool that'll let me do this
>without all of the initial setup work needed to create a F&T
>application. (F&T is more of an EIS or DSS application builder. Not an
>adhoc query builder.) Something like MS Query or along those lines. Do
>you know of any that will allow other applications to run during a
>query?
 

>[warning, incoming soapbox at six o'clock low]
 

>BTW being a Windows programmer myself I find it appalling that people
>are still writing code that doesn't yield control back to Windows when
>it enters a time consuming section. It's really nothing more than a few
>simple lines of code. Not only this but both Microsoft and Petzold say
>that this type of code is unacceptable! (And yet MS-Access breaks their
>own rule!)
 

>Check out PCTools for Windows for examples of how commerical Windows
>applications *should* work in regards to cooperative multitasking. Want
>to seatch the HD for a file, or virus check an entire network drive? No
>problem. Just start the appropriate application, minimize it (cool
>animated icons let you know it's still running), and continue working in
>whatever other application you want.

I suspect that if SQLNet is not 'active' when the result set comes back then network stack has problems with what to do with the data. Because Windows is not pre-emptive I don't see how a time critical action like this can interrupt and take control. I'll bet those PCTools applications do not return control between asking for something from the file server and getting it. They just don't ever ask for very much in one request. SQLNet has no control over what is requested, it could be millions of rows. Received on Wed Nov 23 1994 - 10:41:59 CET

Original text of this message