MSKB article on scalability of ADO/ASP

B

Brian

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
 
A

Anthony Jones

Brian said:
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.
 
B

Brian

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
 
A

Anthony Jones

Brian said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,836
Latest member
BuyBlissBitesCBD

Latest Threads

Top