I have two questions:
In a 2-tier web deployment you are correct.
In a 3-tier web deployment, where the web server communicates with an app server, then GlobalContext and ClientContext obviously provide different capabilities from LocalContext.
In any case, web and app servers are stateless, so once the client request processing is done, everything in memory on the server(s) goes away. That includes all three context dictionaries.
If you need to maintain state on your web server between client requests, you'll need to use standard ASP.NET state management features, such as Session. Of course there are a lot of downsides to maintaining state between client requests, and most web experts would strongly discourage such an approach. At the same time, people _do_ use Session, and I'm sure they sleep OK at night :)
This appears to be a problem. It seems that the ClientContext seem to live past the page life. IE, living as long as the session.
You must make sure that Csla.Web.dll is deployed to the website.
The default context provider uses thread local storage, which is great for pure .NET environments. This will NOT work in an ASP.NET environment due to the way ASP.NET manages its threads.
The ASP.NET context provider (automatically used if Csla.Web.dll is in your web server's bin folder) uses HttpContext to manage all context dictionaries and the User value.
So Jonny is correct, if you have Csla.Web.dll in your bin directory then you should see the correct behavior.
Interesting. I did forget to put the Csla.Web in the Web application. The fact that the Thread collection worked surprises me and scares me at the same time. Ok.
That said, Csla has no API that will use Application and/or Session. Which is fine, I can have my own.
Copyright (c) Marimer LLC