MSKB article on scalability of ADO/ASP

[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

[Anthony Jones]

Re: MSKB article on scalability of ADO/ASP


"Brian" <brian.lukoff@g mail.comwrote in message
news:1159422769 .102647.301270@ i3g2000cwc.goog legroups.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.

[Brian]

Re: MSKB article on scalability of ADO/ASP

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" <brian.lukoff@g mail.comwrote in message
news:1159422769 .102647.301270@ i3g2000cwc.goog legroups.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.

[Anthony Jones]

Re: MSKB article on scalability of ADO/ASP


"Brian" <brian.lukoff@g mail.comwrote in message
news:1159503549 .939416.36780@c 28g2000cwb.goog legroups.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" <brian.lukoff@g mail.comwrote in message
news:1159422769 .102647.301270@ i3g2000cwc.goog legroups.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.

>