Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > MSKB article on scalability of ADO/ASP

Reply
Thread Tools

MSKB article on scalability of ADO/ASP

 
 
Brian
Guest
Posts: n/a
 
      09-28-2006
An MSKB article on the scalability of ADO/ASP
(http://support.microsoft.com/kb/176056/EN-US/) says in a discussion of
why connection objects shouldn't be stored in session variables, "If
you do not pool there will be idle connections wasting server and
network resources. You also have some threading issues that can occur
if multiple concurrent threads end up hitting on the same connection
(though the session ID might save you here, but it is conceivable that
a browser could submit two concurrent requests using the same session
ID and you could get into situation with transactions or with SQL
Server's inability to process more than one command at a time on a
given connection)."

What are the potential threading issues here? (Are there threading
issues even when connection objects are created on each page?) I
thought that even with connection pooling, each connection is only
being used by one user at a time. (And what does this have to do with
Session ID?)

Brian

 
Reply With Quote
 
 
 
 
Anthony Jones
Guest
Posts: n/a
 
      09-28-2006

"Brian" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> An MSKB article on the scalability of ADO/ASP
> (http://support.microsoft.com/kb/176056/EN-US/) says in a discussion of
> why connection objects shouldn't be stored in session variables, "If
> you do not pool there will be idle connections wasting server and
> network resources. You also have some threading issues that can occur
> if multiple concurrent threads end up hitting on the same connection
> (though the session ID might save you here, but it is conceivable that
> a browser could submit two concurrent requests using the same session
> ID and you could get into situation with transactions or with SQL
> Server's inability to process more than one command at a time on a
> given connection)."
>


First off I need to point out that the article is wrong in suggesting that
two concurrent requests may be in progress for the same session ID. Since
the ASP session object is single threaded two ASP requests for the same
session can not be processed at the same time.

> What are the potential threading issues here?


The main issue when you store a reference to any object in the session is
that you affiliate the session with the current thread. From that point on
only this thread can service requests for the session. If you have for
example 500 clients each having a session to thread affiliation you can
start to see requests queuing up whilst worker threads are free. This will
be because the requests waiting for execution can only be serviced by a
specific thread rather than by just any currently idle one. Therefore
scalabiltiy and throughput can be seriously hampered.

>(Are there threading
> issues even when connection objects are created on each page?)


No ADO connection objects as you see them in the ASP code are not pooled
internaly there are other structures which are pooled and these can cross
threads to there are no threading issues here.

> I thought that even with connection pooling, each connection is only
> being used by one user at a time.


In this scenario a connection is removed from the pool and given to a single
thread ADO connection object for it's exclusive use when the ADO connection
is opened. When the ADO connection object is closed the actual connection
is returned to the pool.

> (And what does this have to do with Session ID?)


See above, that article seems a little confused about the role of session in
all of this.

Anthony.


 
Reply With Quote
 
 
 
 
Brian
Guest
Posts: n/a
 
      09-29-2006
Thanks for your help, Anthony. More generally, what sorts of threading
issues do I have to be concerned about when coding in ASP? Could
threading issues ever cause the page to execute incorrectly, or are the
issues always related to the performance of the page?

Brian

Anthony Jones wrote:
> "Brian" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
> > An MSKB article on the scalability of ADO/ASP
> > (http://support.microsoft.com/kb/176056/EN-US/) says in a discussion of
> > why connection objects shouldn't be stored in session variables, "If
> > you do not pool there will be idle connections wasting server and
> > network resources. You also have some threading issues that can occur
> > if multiple concurrent threads end up hitting on the same connection
> > (though the session ID might save you here, but it is conceivable that
> > a browser could submit two concurrent requests using the same session
> > ID and you could get into situation with transactions or with SQL
> > Server's inability to process more than one command at a time on a
> > given connection)."
> >

>
> First off I need to point out that the article is wrong in suggesting that
> two concurrent requests may be in progress for the same session ID. Since
> the ASP session object is single threaded two ASP requests for the same
> session can not be processed at the same time.
>
> > What are the potential threading issues here?

>
> The main issue when you store a reference to any object in the session is
> that you affiliate the session with the current thread. From that point on
> only this thread can service requests for the session. If you have for
> example 500 clients each having a session to thread affiliation you can
> start to see requests queuing up whilst worker threads are free. This will
> be because the requests waiting for execution can only be serviced by a
> specific thread rather than by just any currently idle one. Therefore
> scalabiltiy and throughput can be seriously hampered.
>
> >(Are there threading
> > issues even when connection objects are created on each page?)

>
> No ADO connection objects as you see them in the ASP code are not pooled
> internaly there are other structures which are pooled and these can cross
> threads to there are no threading issues here.
>
> > I thought that even with connection pooling, each connection is only
> > being used by one user at a time.

>
> In this scenario a connection is removed from the pool and given to a single
> thread ADO connection object for it's exclusive use when the ADO connection
> is opened. When the ADO connection object is closed the actual connection
> is returned to the pool.
>
> > (And what does this have to do with Session ID?)

>
> See above, that article seems a little confused about the role of session in
> all of this.
>
> Anthony.


 
Reply With Quote
 
Anthony Jones
Guest
Posts: n/a
 
      09-29-2006

"Brian" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Thanks for your help, Anthony. More generally, what sorts of threading
> issues do I have to be concerned about when coding in ASP?


That's a broad question. If we limit the scope to general ASP script and
common components such as ADO and XML then there are no issues to speak of.
This presumes you already know not to assign references STA objects
(anything that doesn't explicitly state it is FreeThreaded) in the Session
object or the Application object.

>Could
> threading issues ever cause the page to execute incorrectly, or are the
> issues always related to the performance of the page?


Not unless you are writing your own COM components that do unusual things
with threads or are using badly written third party components.


>
> Brian
>
> Anthony Jones wrote:
> > "Brian" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed) ups.com...
> > > An MSKB article on the scalability of ADO/ASP
> > > (http://support.microsoft.com/kb/176056/EN-US/) says in a discussion

of
> > > why connection objects shouldn't be stored in session variables, "If
> > > you do not pool there will be idle connections wasting server and
> > > network resources. You also have some threading issues that can occur
> > > if multiple concurrent threads end up hitting on the same connection
> > > (though the session ID might save you here, but it is conceivable that
> > > a browser could submit two concurrent requests using the same session
> > > ID and you could get into situation with transactions or with SQL
> > > Server's inability to process more than one command at a time on a
> > > given connection)."
> > >

> >
> > First off I need to point out that the article is wrong in suggesting

that
> > two concurrent requests may be in progress for the same session ID.

Since
> > the ASP session object is single threaded two ASP requests for the same
> > session can not be processed at the same time.
> >
> > > What are the potential threading issues here?

> >
> > The main issue when you store a reference to any object in the session

is
> > that you affiliate the session with the current thread. From that point

on
> > only this thread can service requests for the session. If you have for
> > example 500 clients each having a session to thread affiliation you can
> > start to see requests queuing up whilst worker threads are free. This

will
> > be because the requests waiting for execution can only be serviced by a
> > specific thread rather than by just any currently idle one. Therefore
> > scalabiltiy and throughput can be seriously hampered.
> >
> > >(Are there threading
> > > issues even when connection objects are created on each page?)

> >
> > No ADO connection objects as you see them in the ASP code are not pooled
> > internaly there are other structures which are pooled and these can

cross
> > threads to there are no threading issues here.
> >
> > > I thought that even with connection pooling, each connection is only
> > > being used by one user at a time.

> >
> > In this scenario a connection is removed from the pool and given to a

single
> > thread ADO connection object for it's exclusive use when the ADO

connection
> > is opened. When the ADO connection object is closed the actual

connection
> > is returned to the pool.
> >
> > > (And what does this have to do with Session ID?)

> >
> > See above, that article seems a little confused about the role of

session in
> > all of this.
> >
> > Anthony.

>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Scalability of System.IO.File.Exists Brian ASP .Net 0 04-11-2006 12:08 PM
University of Minnesota Selects Cisco Storage Area Network for Scalability, Reliability technology_post@yahoo.com Cisco 0 03-30-2006 05:37 PM
Performance and Scalability of JSP and ASP tharma ASP .Net 4 09-13-2005 06:04 PM
.Net Scalability problem Refky Wahib ASP .Net 1 08-05-2004 01:06 PM
MSKB Article 299692 - How to Upload Files to a Web Server using ASP Brian M ASP General 5 02-20-2004 01:42 PM



Advertisments