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:email@example.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>
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.