ASP.NET

Internal ASP.NET threading model

12-Feb-08 2:23

I'm not a fan of this asp-style coding so I can't really help you unless you're willing to use the asp.net-style code-behind feature... but if you are, run the heading tag on the server and set it's text programmatically:

.aspx:

<h1 id="heading" runat="server" />

Code-behind (.aspx.cs or .vb or ... - I choose C#):

void Page_Load(object sender, EventArgs e)
{
   heading.InnerHtml = Request.Params["itemtype"] + " Items";
}

Notice that this solution has the additional benefit of protecting against script injections because the parameter will be interpreted as HTML code, not just literal text. Hence, a user putting

p.aspx?itemtype=<script>close()</script>

in the adress bar (or more problematically, manages to save an itemtype named so the database, causing other users to be directed to such a url) will render the > and < characters as > and < hence just displaying the text rather than execute the script!

dojohansen11-Feb-08 7:26

11-Feb-08 7:26

Hi,

we're making use of the CallContext class (System.Remoting.Runtime.Messaging.CallContext) to easily share information among objects participating in the same threads. We have a base page class from which we derive our pages, and we initialize this context by handling the Init event in the base page. This seems to work rather brilliantly.

Just to be sure: It is reasonable, isn't it, to assume that this would either *always* work or *never* work? In other words, since the callcontext travels along the logical thread, the init event will never be executed on a different thread from other events in ASP.NET?

ToddHileHoffer11-Feb-08 8:15

11-Feb-08 8:15

You know that the aspnet process does sometimes get reset...

I've nevered needed to use messaging in ASP.Net, can I ask what information you need in multiple threads that can't be stored in the Application state?

I didn't get any requirements for the signature

dojohansen11-Feb-08 23:26

11-Feb-08 23:26

Hi Todd,

I'm afraid you've misunderstood. The CallContext is not for sharing information between threads, but between objects participating in the same thread. ASP.NET itself uses it to provide access to the "intrinsic" objects Request, Response, Server, Handler, Session and so on.

The main reason we can't use asp.net intrinsics such as Session or Application state is that our business layer runs in a non-web context as well. Specifically, we have a windows service that implements a scheduler. This being .net, there should be no problem using the same business layer in the web app and the service, but this of course means the business layer cannot rely on anything asp.net specific.

Another reason is that we perform many long-running tasks which cannot be performed in a synchronous "request - do the work - create the response" manner, but must instead use one request to start work, then go into polling until the work is finished, then get the results. So another reason to avoid relying on the web context is that it enables us to provide identical execution contexts in the threads our code creates as well as those created by asp.net, so business logic can be developed without having to know in advance whether it will take part in "background" threads or not. We keep only a small amount of information here, but it is absolutely essential: The identity of the user, and database connection information. (It is a distributed system and a single application instance can connect to any number of database instances, while also any number of application instances can connect to any given database instance. Hence we need to know on a user-by-user basis what database the user is "logged on to", though we do of course use connection pooling.)

Not using session or app state of course doesn't automatically imply using the CallContext, but it is extremely convenient because it provides isolation between threads, and also because references put into it are removed when the thread ends, so clean-up is automatic much in the same way as with local variables that simply go out of scope.

If anyone has the inside knowledge to answer my actual question rather than try to second-guess what I'm asking (no offense, I appreciate the attempt!) then please let me know. I'm really quite convinced though that it is the same logical thread: asp.net events happen in stages and I can see no reason why one would want to complicate matters by switching threads along the way, when the processing anyway must occur in a linear fashion.

dojohansen11-Feb-08 23:31

11-Feb-08 23:31

I should be more precise about one thing because reading my post I see that I am inviting one misunderstanding: I say that the CallContext is used to provide access to the intrinsic asp.net objects, and that is true. However, I should be more explicit, because otherwise people will think I'm confusing CallContext and HttpContext.

So just to be clear, it is the reference to the current HttpContext which is kept in the CallContext, and the other intrinsics come from that one again.

Basically what we're doing is a sort of simplistic mimicking of the way it's done in asp.net, believing that this design isn't too bad. You could say our business logic relies on a thread context that has been initialized by our own code rather than one initialized by asp.net framework code; thus enabling us to do such initialization in both our scheduler service and the web application.

ToddHileHoffer12-Feb-08 1:31

12-Feb-08 1:31

dojohansen wrote:
If anyone has the inside knowledge to answer my actual question rather than try to second-guess what I'm asking (no offense, I appreciate the attempt!) then please let me know.

What are you talking about?

I didn't try to second guess anything. I've never used messaging in asp.net and I wanted to learn more about it. That's why I asked you...

I didn't get any requirements for the signature

dojohansen12-Feb-08 2:12

12-Feb-08 2:12

I just meant that it seemed you tried to think about state management in general, hence suggesting application state, when in fact my question was whether or not the entire asp.net pipeline is processed on the same logical thread or not. I didn't mean to upset you, so sorry if I did.

I know from when I try to help people that it is often useful to understand the context though, so I try to explain the motivation behind using it.

My testing seems to indicate that Global_BeginRequest and EndRequest fire on a different thread from the page processing, but all events fired on the page appear to always belong to the same thread.

ToddHileHoffer12-Feb-08 2:22

12-Feb-08 2:22

I'd bet money that all page processing occurs on one thread.

I did find this on google.
http://dotnet.org.za/armand/archive/2004/04/07/985.aspx[^]

So it seems you could store and pass data using the CallContext, however judging that only 4 results come back when you google System.Remoting.Runtime.Messaging.CallContext you might have trouble getting any help with this.

I didn't get any requirements for the signature

dojohansen12-Feb-08 3:00

12-Feb-08 3:00

We're pretty much doing the same thing. It is perfect for providing "execution context" information like who is the current user, what's the current database, and so on.

I'm going off on a tangent here, but I actually believe what we've done can be quite useful for others as well.

Our design follows this simple pattern: All instance members are private, as are all constructors. The public interface is static, but public members do nothing but find the right instance and call the corresponding instance member. References to instances are stored in the thread context, hence only one thread can access each instance, so the design is inherently thread-safe.

A snippet demonstrates the pattern implemented in C#:

public class Connection
{
   const string threadKey = "Connection";

   // Private constructor
   Connection(string cnxStr) { ... } 

   // All instance members are private...
   int transactionLevel;
   SqlTransaction transaction;
   SqlConnection sqlConn;
   ...

   // .. including methods
   void beginTransaction()
   {
      ...
   }

   // A *private* static property gets the current instance.
   Connection current
   {
     get 
     {
        Connection c = CallContext.GetData(threadKey) as Connection;
        if (c == null) 
        {
            // This is the only place in the app we need to know where 
            // connection information comes from. :)
            string cnxStr = ...;
            c = new Connection(cnxStr);
        }
        return c;
     }
   }

   // The public interface is all static, giving the illusion that there
   // is only one connection, when in fact there is one per thread.
   static public void BeginTransaction()
   {
      // Just call the corresponding instance method on "current".
      current.beginTransaction();
   }
}

We couple this with our own custom-written "Thread class" (Thread is sealed so our type is not really a thread, but it has the same interface as a thread so where our code was creating threads we just switched the type to our own) which copies the execution context of the thread that creates it, and we have a wonderfully simple to use solution with a minimum of code redundancy. (The "where do connection info come from" logic was all over the place before, and we had problems knowing when we should clone connections and when we should not, because the method using a connection would sometimes be called as part of a transaction and sometimes without one, sometimes in a thread processing a page request and sometimes in a background thread... Using the call context and our pretend-thread class solved all these problems and simplified the programming of application logic to boot!

The code it leads to is just as simple as code reading or writing a Session variable, though of course there are many session instances at any given time in the application domain. Only it is even better because no reference to the object exists outside the type itself, making it far easier to avoid memory leaks.

In the past we even had business objects that contained a reference to an instance of HttpSessionState,

myObj.Session = Session;

and this sort of terrible thing too is avoided with this design, at the expense of a larger number of lookups of course. The overhead doesn't seem to be that big though. In 1.x the HttpContext.Current also came from here (I checked with Reflector) so I'm figuring it can't be that bad.

This of course is all proprietary information Big Grin | :-D

ToddHileHoffer12-Feb-08 3:16

Request is not available in this context

12-Feb-08 3:16

Nice.

You might want to write up an article about this...

I didn't get any requirements for the signature

Ryno Burger11-Feb-08 6:34

Ryno Burger

11-Feb-08 6:34

Hi guys

I have a function called SendEmail which runs within a thread.

This function simply send an email to the user.

However, I made a "Please Wait..." page while the email gets send in the background the user see the "Please Wait..." page.

<br />
public void SendEmail()<br />
{<br />
StringBuilder messageText = new StringBuilder();<br />
<br />
messageText.AppendLine(string.Format("Name: {0} {1}", txtName.Text.Trim().ToString(), txtSurname.Text.Trim().ToString()));<br />
messageText.AppendLine(string.Format("Contact Number: {0}", txtContactNumber.Text.Trim().ToString()));<br />
messageText.AppendLine(string.Format("Email Address: {0}", txtEmail.Text.Trim().ToString()));<br />
messageText.AppendLine(string.Format("Comments: {0}\n\n", txtComments.Text.Trim().ToString()));<br />
messageText.AppendLine(string.Format("Quote Reference Nr: {0}", Request.QueryString["quoteNr"].ToString())); // Breaks here with error: Request is not available in this context<br />
<br />
// Send the email to the user<br />
}<br />

I call the SendEmail() function using the following lines of code:

<br />
Guid id = Guid.NewGuid();<br />
<br />
ThreadStart ts = new ThreadStart(SendEmail);<br />
<br />
Thread th = new Thread(ts);<br />
<br />
th.Start();<br />
<br />
Response.Redirect(string.Format("PleaseWait.aspx?ID={0}&type={1}", id, "email"));<br />

Is it true that you can't access Request data within a thread, if not, how do I then get access to Request.QueryString data?

Re: Request is not available in this context

dojohansen11-Feb-08 7:49