Wrox Home  
Search P2P Archive for: Go

  Return to Index  

asp_discuss thread: RE: Session Variable Capacity


Message #1 by rtb@M... on Thu, 6 Sep 2001 22:46:21
Hal,



Much impressed with your previous reply...could you please help with these 

questions?  



1. What are the benifits of using COM objects with ASP?



2. If you process your SQL statements in the COM object (i.e. preform an 

update) will this be faster than processing them on the page?



3.  Is the processing done at all on the client side?



Thanks a ton for your reply...



Sincerely,



Ryan Brooks

Web Developer

Municipal Code Corporation



> 

> Can you? Yes.

> 

> Option One:

> You can create the connection and the recordset in the session. Keeping 

the

> connection open and the recordset open. 

> Don't do it. This will cause blocking on connections, slow down 

performance,

> and in general is a very bad idea.

> 

> Option Two:

> You can create a connection and recordset on the page level- get all the

> data and store that into an array in the session object.

> Less troublesome than the open connection and recordset. This is still 

going

> to impact performance negatively (especially on a moderately heave volume

> site- or more) but is much better than the first option.

> 

> Option Three:

> Create the connection on each page and re-query the database.

> This is an even better option. The connection is pooled so the "spin up

> time" on the connection is pretty much non-existent. The dB has cached 

the

> results- so you will get them back quicker.

> 

> Option Four:

> Create a connection on each page, but this time have your Query in a 

Stored

> Proc and just call that.

> Even Better. All the benefits of option three PLUS the SQL is pre-

compiled

> and pre-optimized by the SQL engine to make things even faster.

> 

> Option Five:

> Create a COM object that makes your data connection and that calls the

> stored procedure and return an array from the COM object.

> Now we are cooking with Gas! We have all the benefits of the above- and 

it's

> much easier to get at your data. It lets you re-use the logic on multiple

> pages in an efficient way and, if your under MTS or COM+ you get an 

object

> cache to boot!

> 

> 

> Notice that the only one I said you absolutely shouldn't do was storing 

your

> Connection and Recordset in the session. This is a VERY bad idea. Any of 

the

> others are "acceptable".

> 

> Hal Levy

> StarMedia Network, Inc.

> Intranet Development Manager 

> 

Message #2 by Hal Levy <hal.levy@s...> on Fri, 7 Sep 2001 08:20:44 -0400

Answers Inline.



Hal Levy

StarMedia Network, Inc.

Intranet Development Manager 



> -----Original Message-----

> From: rtb@M... [mailto:rtb@M...]

> Sent: Thursday, September 06, 2001 6:46 PM

> To: asp_discuss

> Subject: [asp_discuss] RE: Session Variable Capacity

> 

> 

> Hal,

> 

> Much impressed with your previous reply...could you please 

> help with these 

> questions?  

> 

> 1. What are the benifits of using COM objects with ASP?

> 



COM is compiled. It runs Faster than ASP- which is the appropriate way to

handle your business logic.  Right now the way I am doing my architectures

is COm objects that output XML. Then I use ASP to merge the XML with an XSLT

and then apply CSS to that output.





> 2. If you process your SQL statements in the COM object (i.e. 

> preform an 

> update) will this be faster than processing them on the page?

> 



Much- even faster is creating a stored procedure- this is N-Tier

development. Your SQL statements are stored proc's . You call the stored

Procs from your COM object where you do your business work (math, Rule

checking, etc.) and then send the result to ASP for the display.



> 3.  Is the processing done at all on the client side?



That depends on what you do. If you write a Java applet or ActiveX Control

and tell it to run on the client- then it will. otherwise it's all server

side.





> Thanks a ton for your reply...

> 

> Sincerely,

> 

> Ryan Brooks

> Web Developer

> Municipal Code Corporation

>

  Return to Index