RE: Web enablement options (previously private)

Actually the host servers are prestart jobs, so there is a little less
overhead.

The important thing you're missing though is connection pooling on the OLEDB
side. In my ASP I would open a connection, run the SQL and close the
connection. However, the reality of it is that the first time I open a
connection the driver connects to the host server. When I close my
connection the driver says, "Hey, I know he'll be back." So the driver
doesn't close the connection. Next time I open a connection the driver say
"Hey, have I got a deal for you" and hands me an open connection. Once my
site is humming there are very few job starts and ends.

As you go through advanced ASP you'll see repeated over and over "Close the
connection as soon as possible!!" and connection pooling is the reason. Even
my recordsets are crafted to allow me to disconnect the recordset from the
connection and then process the set. The connection is freed back to the
pool.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
Sent: Friday, January 04, 2002 15:53
To: MIDRANGE-L@midrange.com
Subject: Re: Web enablement options (previously private)

<snip>

However, the Host Servers that you connect to (in my opinion) were not
designed for the dynamics of Web applications.  A new host server job is
activated for each connection.  Then after that, the stored procedure is
activated.  After the run, the stored procedure is deactivated, and the host
server job ends.  It consumes significant CPU time.  You run into even more
difficult scalability issues than you do with CGI.

<snip>