|
 |
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
>
|
|
 |