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==?=" <
[email protected]>
| References: <
[email protected]>
<
[email protected]>
| Subject: RE: Using CallContext to store request specific objects
| Date: Tue, 25 Oct 2005 09:58:07 -0700
| Lines: 30
| Message-ID: <
[email protected]>
| 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?
|