MSKB article on scalability of ADO/ASP

Discussion in 'ASP General' started by Brian, Sep 28, 2006.

  1. Brian

    Brian Guest

    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
     
    Brian, Sep 28, 2006
    #1
    1. Advertising

  2. "Brian" <> wrote in message
    news:...
    > 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, Sep 28, 2006
    #2
    1. Advertising

  3. Brian

    Brian Guest

    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" <> wrote in message
    > news:...
    > > 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, Sep 29, 2006
    #3
  4. "Brian" <> wrote in message
    news:...
    > 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" <> wrote in message
    > > news:...
    > > > 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, Sep 29, 2006
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nita
    Replies:
    1
    Views:
    888
    Saravana
    Nov 20, 2004
  2. ronaldlee

    Transfer ADO Code to ADO.NET

    ronaldlee, Dec 17, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    477
    Kevin Spencer
    Dec 17, 2004
  3. Replies:
    0
    Views:
    1,330
  4. Navin
    Replies:
    1
    Views:
    727
    Ken Schaefer
    Sep 9, 2003
  5. Brian M
    Replies:
    5
    Views:
    142
    Vilmar Braz√£o de Oliveira
    Feb 20, 2004
Loading...

Share This Page