Using CallContext to store request specific objects

Discussion in 'ASP .Net' started by =?Utf-8?B?RXhjbHVzaXZlUmVzb3J0cw==?=, Oct 24, 2005.

  1. Can the CallContext be used reliably for storing request specific data?

    We are developing an application library that uses the CallContext to keep
    an IdentityMap (hashtable of business objects that have been loaded from the
    DB) and a collection of business objects that have been modified during the
    current request. These object maps need to be globally visible throughout a
    request and expire at the end of it. The maps are accessed using static
    methods of a manager class which uses CallContext.GetData().

    For example: If two different web requests load a Person
    object with an ID of 100, then two reads would be performed on the database
    and two IdentityMaps would be created. Within one executing web request, if
    a Person object with an ID of 100 is read twice then the second object would
    would come from the IdentityMap.

    This is working great in our development environment but we have some
    concerns that under load the CallContext may not be unique to the current
    request and may not be the best choice for this. However, since the
    application can be used outside of a web context the HttpContext could not be
    used.
     
    =?Utf-8?B?RXhjbHVzaXZlUmVzb3J0cw==?=, Oct 24, 2005
    #1
    1. Advertising

  2. Hi Exclusive,

    Welcome to ASPNET newsgroup.
    Regarding on the question you mentioned, I think your current approach on
    using the CallContext should be OK and due to the limitation that you can
    not utilzie the HttpContext class, I'm afraid there hasn't any other better
    buildin interfaces for maitains data during execution path. Also, the
    current implementation of the HttpContext.Current also utilize the
    Callcontext to associate the context data with the executing asp.net
    serverside request. In addition, if your class component is only used in
    single appdomain scenario, we can also consider implementing a custom class
    which use static class member to hold a collection which store the data for
    each request by a identity number...

    Thanks,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)





    --------------------
    | Thread-Topic: Using CallContext to store request specific objects
    | thread-index: AcXY7bAMKWoJJsSTS4GNrK2YMPbGbQ==
    | X-WBNR-Posting-Host: 198.67.7.2
    | From: "=?Utf-8?B?RXhjbHVzaXZlUmVzb3J0cw==?=" <>
    | Subject: Using CallContext to store request specific objects
    | Date: Mon, 24 Oct 2005 15:53:02 -0700
    | Lines: 20
    | Message-ID: <>
    | MIME-Version: 1.0
    | Content-Type: text/plain;
    | charset="Utf-8"
    | Content-Transfer-Encoding: 7bit
    | X-Newsreader: Microsoft CDO for Windows 2000
    | Content-Class: urn:content-classes:message
    | Importance: normal
    | Priority: normal
    | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
    | Newsgroups: microsoft.public.dotnet.framework.aspnet
    | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
    | Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
    | Xref: TK2MSFTNGXA01.phx.gbl
    microsoft.public.dotnet.framework.aspnet:133594
    | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
    |
    | Can the CallContext be used reliably for storing request specific data?
    |
    | We are developing an application library that uses the CallContext to
    keep
    | an IdentityMap (hashtable of business objects that have been loaded from
    the
    | DB) and a collection of business objects that have been modified during
    the
    | current request. These object maps need to be globally visible
    throughout a
    | request and expire at the end of it. The maps are accessed using static
    | methods of a manager class which uses CallContext.GetData().
    |
    | For example: If two different web requests load a Person
    | object with an ID of 100, then two reads would be performed on the
    database
    | and two IdentityMaps would be created. Within one executing web request,
    if
    | a Person object with an ID of 100 is read twice then the second object
    would
    | would come from the IdentityMap.
    |
    | This is working great in our development environment but we have some
    | concerns that under load the CallContext may not be unique to the current
    | request and may not be the best choice for this. However, since the
    | application can be used outside of a web context the HttpContext could
    not be
    | used.
    |
     
    Steven Cheng[MSFT], Oct 25, 2005
    #2
    1. Advertising

  3. Steven,

    Thanks for the quick response. In your response you said that our approach
    to using the CallContext “should be okâ€. We were wondering if you could be a
    little more specific.

    Again, our concern is that the integrity of the data contained in the
    CallContext may not be maintained during instances of high traffic and
    concurrency on the web server.

    We have read that the CallContext is tied to a thread. We have also read
    that the processing of a single asp.net page and all of it’s business objects
    cannot be guaranteed to execute on the single thread. Because of this we
    have deduced that CallContext may not be a reliable source of data.

    Specific Questions:

    Is the processing of a single asp.net page and all of it’s business objects
    tied to a single thread?

    Is there a limit to the amount of data you can store in the CallContext?

    Can we be assured that the data contained in the CallContext is only
    available to each specific request?

    Is all memory ‘released when the thread a request executed on is given back
    to the thread pool?

    Is there an easy way to test the above and be assured we will not have any
    issues?
     
    =?Utf-8?B?RXhjbHVzaXZlUmVzb3J0cw==?=, Oct 25, 2005
    #3
  4. Thanks for your response,

    For your further question:

    1) Is the processing of a single asp.net page and all of it’s business
    objects
    tied to a single thread?
    ================================
    Yes, ASP.NET runtime will pickup a .net managed thread pool thread from CLR
    thread pool when a new asp.net request arrive the asp.net runtime. Then,
    that worker thread is associated with that request during serverside
    processing/lifecycle. After that request eneded, the worker thread return
    to the threadpool again for sequential use. New thread will be involved
    only when we manually create new thread to do works or use asynchornous
    method invoking (e.g. delegate.BeginInvoke....)


    2)Is there a limit to the amount of data you can store in the CallContext?
    ================================
    As far as I known, there hasn't any documented limitation on the
    CallContext's data storage. It'll depend on the actual server's memory just
    like sessionstate or asp.net runtie Cache....


    3)Can we be assured that the data contained in the CallContext is only
    available to each specific request?
    ================================
    Of course I think so. As I mentioned, the "HttpContext.Current"( which
    always point to the HttpContext of the current asp.net request/worker
    thread) ) just utilize the CallContext to retrieve the stored Context
    object, so the CallContext is reliable.


    4)Is all memory released when the thread a request executed on is given
    back
    to the thread pool?
    ================================
    Do you mean all the memory of the data stored in the CallContext? If so, I
    think they'll be cleared because CallContext is a very context sensitive
    field which should be reset before the thread pool thread be resued next
    time. However, for some other properteis of the Thread pool thread, we're
    not gurantee that they'll be reset(because for performance consideration,
    thread pool thread won't intialize all the fields/properties before being
    picked to serve a certain request.


    5)Is there an easy way to test the above and be assured we will not have
    any
    issues?
    =================================
    No definite answer on this. For low workload scenario, I'm sure this will
    works ok. So the simplest means I can get is performing high workload
    concurrent test on this. ( you can increase he maxWorkerThreads setting in
    <processModel> cofiguration section in machine.config according to your
    requirement and machine's hardware )

    <processModel> Element
    http://msdn.microsoft.com/library/en-us/cpgenref/html/gngrfprocessmodelsecti
    on.asp?frame=true

    Hope helps. Thanks,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)



    --------------------
    | Thread-Topic: Using CallContext to store request specific objects
    | thread-index: AcXZhUXWJ0a/cEImRsmvVJgGBUgc7A==
    | X-WBNR-Posting-Host: 198.67.7.2
    | From: "=?Utf-8?B?RXhjbHVzaXZlUmVzb3J0cw==?=" <>
    | References: <>
    <>
    | Subject: RE: Using CallContext to store request specific objects
    | Date: Tue, 25 Oct 2005 09:58:07 -0700
    | Lines: 30
    | Message-ID: <>
    | MIME-Version: 1.0
    | Content-Type: text/plain;
    | charset="Utf-8"
    | Content-Transfer-Encoding: 8bit
    | X-Newsreader: Microsoft CDO for Windows 2000
    | Content-Class: urn:content-classes:message
    | Importance: normal
    | Priority: normal
    | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
    | Newsgroups: microsoft.public.dotnet.framework.aspnet
    | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
    | Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
    | Xref: TK2MSFTNGXA01.phx.gbl
    microsoft.public.dotnet.framework.aspnet:133753
    | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
    |
    | Steven,
    |
    | Thanks for the quick response. In your response you said that our
    approach
    | to using the CallContext “should be ok� We were wondering if you
    could be a
    | little more specific.
    |
    | Again, our concern is that the integrity of the data contained in the
    | CallContext may not be maintained during instances of high traffic and
    | concurrency on the web server.
    |
    | We have read that the CallContext is tied to a thread. We have also read
    | that the processing of a single asp.net page and all of it’s business
    objects
    | cannot be guaranteed to execute on the single thread. Because of this we
    | have deduced that CallContext may not be a reliable source of data.
    |
    | Specific Questions:
    |
    | Is the processing of a single asp.net page and all of it’s business
    objects
    | tied to a single thread?
    |
    | Is there a limit to the amount of data you can store in the CallContext?
    |
    | Can we be assured that the data contained in the CallContext is only
    | available to each specific request?
    |
    | Is all memory ‘released when the thread a request executed on is given
    back
    | to the thread pool?
    |
    | Is there an easy way to test the above and be assured we will not have
    any
    | issues?
    |
     
    Steven Cheng[MSFT], Oct 26, 2005
    #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. Brian Birtle
    Replies:
    2
    Views:
    2,055
    John Saunders
    Oct 16, 2003
  2. Pham Nguyen
    Replies:
    5
    Views:
    918
    Finn Hart
    Mar 9, 2005
  3. =?Utf-8?B?UnVkeQ==?=

    to store or not to store an image

    =?Utf-8?B?UnVkeQ==?=, Mar 29, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    645
    =?Utf-8?B?UnVkeQ==?=
    Mar 30, 2005
  4. 7stud
    Replies:
    11
    Views:
    700
    Dennis Lee Bieber
    Mar 20, 2007
  5. Replies:
    7
    Views:
    391
    David Lamb
    Oct 29, 2012
Loading...

Share This Page