Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Three Commandments for ASP Programming  : Page 2

As ASP programmers you must resolve to code better, more efficiently, and with performance in mind. Here are some resolutions I hope you will adopt and stick to.


advertisement

Never Place an OBJECT in a Session/Application Variable
Do you like using session variables? Are you fond of placing any and every value within a session variable? That's okay, but please be careful. Never place an OBJECT within a session variable. How do you know if you're doing this? Check your code. If it begins like this:


Set Session("variablename

you are placing an OBJECT within a session variable. (An object always needs a SET statement for assignment—at least in all current versions of ASP.)



For example, you may have created an ADO recordset object or connection object and want to store it in a session variable so that you do not have to create it again, but can reuse the same object over and over again in your session. You are effectively crippling the Web server by doing anything like this. Why? The key words here are thread affinity and serialization.

Placing an ADO connection object in an application level variable is easy:


Dim objCONN
Set objCONN = Server.CreateObject("ADODB.Connection")
objCONN.Open "Your connection string here"
' - place it in an application variable
Application.Lock
Set Application("objCONN") = objConn
Application.Unlock

Using it later on in your ASP page is also very easy:


Dim strSQL, objRS
StrSQL = "Select * from Customers"
Set objRS = Application("objConn").Execute (strSQL)

If you have stored an ADO connection object in an application level variable, you know that the variable is maintained till the Web server is shut down (the application ends). However, did you know that the variable is maintained on a specific thread? This is referred to as thread affinity. Any script that tries to access the variable has to either be on the same thread to make the call or must translate the call to the specific thread (a process called marshalling), which is a very expensive call to make. This results in lower performance.

If more than one ASP page is trying to make a call to a specific thread, they are placed in a row, one after the other to wait their turn before they can make the call. They are forced to run in a sequence. This is called serialization. Again, this results in performance degradation as your site serves more and more requests.

IIS is built to operate on multiple threads—a multi-threaded application. By placing objects in application level variables and forcing the Web application to wait for a specific thread to become active and run within it, you are forcing IIS to behave like a single threaded, inefficient application—effectively crippling its power.

The bottom line: Never place an OBJECT within a session variable. Learn more about this topic in Microsoft's article " INFO: Do Not Store STA Objects in Session or Application" Also, check out another great site LearnASP.com and its specific advice on ADO objects and session variables.

Note that the above piece of advice applies only to Single-threaded Apartment (STA) components, i.e., all Visual Basic COM components and ADO objects.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap