In the following example, I am setting a value to an AsyncLocal<string> variable on my HttpApplication subclass (i.e. Global.asax) from within Application_BeginRequest():
public class Global : System.Web.HttpApplication
{
public static AsyncLocal<string> AsyncLocalState = new AsyncLocal<string>();
protected void Application_BeginRequest(object sender, EventArgs e)
{
AsyncLocalState.Value = HttpContext.Current.Request.Path;
}
protected void Application_AuthenticateRequest(object sender, EventArgs e)
{
var path = AsyncLocalState.Value;
}
protected void Application_EndRequest(object sender, EventArgs e)
{
var path = AsyncLocalState.Value;
}
}
Later on, I will attempt to access the value of this AsyncLocal variable from within a handler, such as an MVC action method, or even just a plain IHttpHandler.
If I send a large enough request (e.g. a POST with more than 15KB of data -- the larger the request, the easier it is to observe), there is a very good chance that the value of AsyncLocalState is NULL when accessed from a handler even though it was set on BeginRequest.
This is reproducible from a brand-new ASP.NET project without any other libraries/modules/handlers loaded.
Is this a bug? Or maybe I'm doing something wrong? Or is ASP.NET just too unstable for this?
Addition note: the exact same behavior is observed if I instead use CallContext.LogicalGetData/CallContext.LogicalSetData.
Platform: ASP.NET, .NET 4.6.2, on Windows 7
Update: After trying to dig around, I've found a lot of references to, but nothing authoritatively saying that the ExecutionContext does not flow between ASP.NET pipeline events (except when it does?). And both AsyncLocal and the logical call context are based on the ExecutionContext.
The closest thing to an authoritative answer is this comment by David Fowl on GitHub.
The ExecutionContext does not flow between ASP.NET pipeline events if these events do not execute synchronously. Therefore, don't use AsyncLocal or the logical CallContext to persist state; use HttpContext.Items.
Update: .NET 4.7.1 adds a new callback method, HttpApplication.OnExecuteRequestStep, which per documentation "provides extensibility to the ASP.NET pipeline to make it easy for developers to implement features in ambient context scenarios and build libraries that care about ASP.NET execution flow (for example, tracing, profiling, diagnostics, and transactions)."
This is precisely what someone would need in order to restore the AsyncLocal state or the logical CallContext between ASP.NET pipeline events.
Related
I have read source code of one web application and seen that it used Cache object( Web.Caching.Cache) for caching data. In code behind files( aspx.cs files), it uses Page.Cache to get Cache while in others class-define files it uses HttpContext.Current.Cache to get Cache. I wonder why it not use the same option to get Cache. Can someone explain differences between Page.Cache and HttpContext.Current.Cache? Why use each one for each context above. Can I use Page.Cache or HttpContext.Current.Cache for both contexts above?
Thanks in advance.
There is no difference, the former uses the current page instance and it's Cache property, the latter uses the static approach via HttpContext.Current.Cache which would work also in a static method without page instance.
Both are referring to the same application cache.
So you can get the Cache via Page, for example in Page_Load:
protected void Page_load(Object sender, EventArgs e)
{
System.Web.Caching.Cache cache = this.Cache;
}
or in a static method (which is used in a HttpContext) via HttpContext.Current:
static void Foo()
{
var context = HttpContext.Current;
if (context != null)
{
System.Web.Caching.Cache cache = context.Cache;
}
}
I am getting the following error
'Event handlers can only be bound to HttpApplication events during IHttpModule initialization.' at the following code (line in bold or double **)
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
**app.EndRequest += new EventHandler(Application_EndRequest);**
}
protected void Application_EndRequest(object sender, EventArgs e)
{
UnitOfWork.Commit();
}
which is mentioned in Global.asax file. Can anybody figure out, where I am lacking? Thanks.
The event handler lives the entire life of your application, so, you only need to add it once not add it every request. The event itself will fire every request, and the only-one handler will be called every time the event is raised.
Add it to Application_Start in global.asax not Application_BeginRequest, or better, create an HTTP Module instead.
Also, I think you may not even need an event handler. The method with current name will be called by convention similar to Page/Control AutoEventWireup (like Page_Load). Just note that this might have issues in ASP.NET MVC applications as some people report. So, my suggestion is to rename the function, add the event handler in Application_Start, or better in a new HTTP Module you create.
Try to comment out line marked with "**". Asp.Net will call appropriate methods by itself if followed by naming conventions: "{Scope}"_"{Event}", where "{Scope}" is Application if you want to handle application level events or "Session" if you want to handle session level events, and "{Event}" is name of the event, like Start, End, etc.
More info: http://msdn.microsoft.com/en-us/library/bb470252.aspx#Stages
I'm using ASP.NET 4.0 on IIS7.5 and WCF Callback technique. I have no problem with callback. The wcf service can fire callback method in web client but it seems it's on another thread with the UI thread.
public partial class _Default : System.Web.UI.Page, IServiceCallback
{
private IService proxy = null;
private static TextBox _textBoxtest;
protected void Page_Load(object sender, EventArgs e)
{
_textBoxtest = TextBox1;
}
protected void Button1_Click(object sender, EventArgs e)
{
//then server will call back to FireCallBackFromServer
proxy.CallService(type, "someObject");
}
#region IServiceCallback Members
public void FireCallBackFromServer(string txt)
{
TextBox1.Text = txt; <-- the value does not update on textBox
}
#endregion
}
Please help me to think how to update my textBox from callback event.
Thank you.
It is how WCF callback works. Each callback call is served by its own thread. I think the reason why this happens is because you don't have SynchronizationContext which will point incomming request back to current thread (and hopefully current instance of your page). The contrary example are callbacks used in WPF or WinForm applications. UI thread in these applications by default has SynchronizationContext so if you open service proxy in UI thread, requests to callback are routed back to UI thread - it sometimes causes another problems so you can turn off usage of SynchronizationContext in ServiceBehaviorAttribute.
But even if you solve this problem you will deal with the same problem in ASP.NET. Each request to ASP.NET creates new instance of handler. So each request from your browser will create new instance of page.
I believe that if client is ASP.NET then WCF callback doesn't make sense because I still didn't see any working implementation.
I've run into this issue, where only the UI thread can perform UI updates, in a WPF application using WCF callbacks. I don't do much work in ASP.NET, so I'm not 100% sure the answer is the same but the problem looks very similar.
The way I solved the problem was to use the Dispatcher and lambdas to send the change to the UI thread. Put into the context of your code, it would look something like
public void FireCallBackFromServer(string txt)
{
Dispatcher.CurrentDispatcher.BeginInvoke(new Action(() => TextBox1.Text = txt;));
}
This should update your textbox's content to the text provided in the callback. Give it a try and see how you go.
I have the following assemblies in my ASP.NET app:
Website - this is an ASP.NET website
ClassLib - this is just a class lib that contains all the business logic
Class Lib needs to interact with the HttpContext Session and Request objects. This is a code upgrade from an old ASP app, where I've hoovered all the VBScript that contained the logic and put it into VB.NET. We simply didn't have time to rewrite.
Instead of ClassLib interacting directly with HttpContext, which I thought was BAD and also prevented us from unit testing, I introduced the following abstraction layer:
Public Class Request
Private Shared _requestWrapper as IRequestWrapper
Public Shared ReadOnly Property RequestWrapper()
Get
If _requestWrapper Is Nothing Then
Throw New Exception("_requestWrapper is null. Make sure InitRequest() is called with valid parameters")
End If
Return _requestWrapper
End Get
End Property
Public Shared Sub InitRequest(ByRef requestWrapper As IRequestWrapper)
_requestWrapper = requestWrapper
End Sub
Public Shared Function GetVal(ByVal key As String) As Object
Return RequestWrapper.GetVal(key)
End Function
etc.
This means in the unit tests I can supply my own MockRequest object into this Request class, which is just a simple NameValue collection. The code in the ClassLib and the Website then simply use the Request class and are none the wiser that it isn't coming from the HttpContext, but rather this mock class.
When it comes to the real deal, I simply have the following (C#) class:
public class RealRequest : IRequestWrapper
{
public void Initialize(HttpContext context)
{
}
#region Implementation of IRequestWrapper
public object GetVal(string index)
{
return HttpContext.Current.Request[index];
}
etc.
This is initialised in Session_Start of global.asax in the Website, as follows:
protected void Session_Start(object sender, EventArgs e)
{
IRequestWrapper requestWrapper = new RealRequest();
WebSession.Request.InitRequest(ref requestWrapper);
}
I think this is similar to the Static Gateway pattern.
Now, I am aware of singletons and static vars in a multi threaded environment such as ASP.NET, but this is slightly different. When it gets down to the RequestWrapper.GetVal(), its actually going to the HttpContext for that running thread - and pulling the value from that.
Certainly, any concurrent tests that we do with multiple users hitting the same server have never shown up any strange behaviour.
I'm just looking for re-assurance that this is a sound design, and if not why not?
Thanks
Duncan
This is fine. We have a very similar case in our applications that either uses HttpContext if it exists or fake implementations otherwise.
The one thing to watch out for is that there is a very specific instance where HttpContext.Current will return a value but HttpContext.Current.Request will throw an exception when triggered by the Application_Start event. In framework code, you really don't know (or want to know) what triggered the call though.
Workaround for HttpContext.HideRequestResponse being internal? Detect if HttpContext.Request is really available?
I have two questions:
1) I have a few global variables for my website declared in my global.asax file. They are simple, small key/value pairs and there are only a few of them. Is this a good practice for values that are small and need to be accessed by almost every page on my website? Storing them in the database and requiring a db lookup seems as thought it would waste resources for values that don't change rapidly.
2) If one of the values changes once per week, is it possible to allow a user to edit the global variable with a form or some other means?
Example:
<script runat="server">
Overloads Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
Application("default_scoring_id") = 3
Application("week_current") = 3
End Sub
</script>
In the above example, the system needs to know which week (out of 15 of them) that the current date is within. So, once every Monday morning, the "week_current" value needs to change.
I can easily do this, but is there a way to give a user access to changing this value without touching the code?
The typical practice is to put these into the web.config, which can be edited. These <appSettings> values will then be available on every page, yet the file can be edited.
1) Good practice is usually to store those sort of values in the web.config. See here and here for some guides.
2) a) If you store this in the web.config it will be easily updatedable without the need for recompiling and the web application should immediatly pick up the changes.
b) Does updating something like the 'week number' really need to be a manual process? It sounds a bit error prone and i would suggest automating this if at all possible by calculating it based on the current date.
I would consider using the built in Cache (System.Web.Caching.Cache)
That way you can store them where ever you want (say in a database), change them from within the app easily, and have quick and cheap retrieval.
From within a class which inherits from BasePage use the given Cache object (eg Cache.Add(..)) and from elsewhere use HttpContext.Current.Cache (eg. HttpContext.Current.Cache.Remove(Key))
The other answers suggest the different ways this can be done, and must be done. But, even then if you want to allow the user to edit the global variable, you'll have to take a lock or Mutex on a shared object, change the value of your global variable, and release the lock or Mutex.
lock(globalsharedobject) //This is C# code.
{
Application("default_scoring_id") = 3;
}
Web.config is the .NET way, or ASP.NET way, it's not always the most efficent or most suitable.
You're Global.asax file is much more than some events, you can put static data in any class that subclass System.Web.HttpApplication and inherit that in your Global.asax file.
The HttpSessionState and HttpApplicationState are relics, from the classic ASP time and you would do well to avoid them, becuase the serve no real purpose.
Depending on the type (System.Type) of your objects you can design your own strongly typed objects that store information about your application and session, for application level data a bunch of static fields would be enough.
They have to be static becuase each HttpModule as well as HttpApplication instance are pooled object, so to avoid that confusion, make sure your persistent data is stored in a static or several static dicionaries. But be aware of concurrency issues when modyfying these collections. A good strategy is to lock the object, only for the duration you're modifying it and make sure you don't call any other code while modyfiny the collection, a simple swap idiom, might be helpful here, it's fast and it's a non-deadlock guarntee.
<%# Application Language="C#" %>
<script runat="server">
void Application_Start(object sender, EventArgs e)
{
// Code that runs on application startup
}
void Application_End(object sender, EventArgs e)
{
// Code that runs on application shutdown
}
void Application_Error(object sender, EventArgs e)
{
// Code that runs when an unhandled error occurs
}
void Session_Start(object sender, EventArgs e)
{
// Code that runs when a new session is started
}
void Session_End(object sender, EventArgs e)
{
// Code that runs when a session ends.
// Note: The Session_End event is raised only when the sessionstate mode
// is set to InProc in the Web.config file. If session mode is set to StateServer
// or SQLServer, the event is not raised.
}
protected void Application_BeginRequest(Object sender, EventArgs e)
{
Context.Items.Add("Request_Start_Time", DateTime.Now);
}
protected void Application_EndRequest(Object sender, EventArgs e)
{
TimeSpan tsDuration = DateTime.Now.Subtract((DateTime)Context.Items["Request_Start_Time"]);
Context.Response.Write("<b>Request Processing Time: From Global.asax file " + tsDuration.ToString());
Application["time"] = tsDuration.ToString();
}
</script>