Running CSLA 4.2 / SL using IIS/AppFabric in the middle. In the DalManager's constructor, I check for the existing of a key in ApplicationContext.ClientContext. If the key doesn't exist, I call a method to get connection string data so that I can then put it into the ClientContext for all subsequent calls to use. Here's the code:
// see if the connection string is already available in the ClientContext
if ((Csla.ApplicationContext.ClientContext == null) ||
(Csla.ApplicationContext.ClientContext.Contains("AppConnString") == false))
{
ev.WriteInformationEvent("GetConnString called", "connection string is empty");
// ClientContext does not contain the connection string, so retrieve it from Rover
Csla.ApplicationContext.ClientContext["AppConnString"] = GetConnectionString();
}
The problem is that when I look at the event log on AppFabric, the GetConnectionString() method is called many times when the main page loads. There are a few objects that are involved for that page, so I'm sure that there are multiple fetches going on. But my intention with using ClientContext was that after the first execution of the DalManager constructor, the connection string would be stored for all subsequent fetches and it wouldn't keep calling my GetConnectionString method. Is ClientContext not the right place to store this? Why would subsequent calls always show that ClientContext doesn't contain my AppConnString key? Thanks.
OK - I just re-read about the Application Context in the DataAccess e-book, and saw this:
It seems I might have misunderstood the ClientContext. According to the first bullet point above, client context gets copied from the client to the server on every call. In my case, the client isn't executing my aforementioned code, the server is. So with each request the ClientContext is being passed empty from the client to the server.
What should I do in my case where I want data to remain on the server between calls (and that data isn't stored and shouldn't be available on the client)? Must I use GlobalContext? I just remember Rocky mentioning something about using GlobalContext sparingly due to performance implications. Thanks, again.
By default, web servers don't remember anything from request to request. There are solutions to this: Session, disk files, databases, caching. Each has its good and bad points, and the whole area is quite complex.
CSLA doesn't do anything to alter normal web server behavior - it is virtually impossible to anticipate which server state management scheme someone might use, or to create an abstraction that would work with any of the many variations on solutions.
When a data portal request ends, IIS/ASP.NET drop all state from that request. So none of the CSLA context dictionaries can survive.
And that's good, because the thread that just finished serving your request will almost certainly be used next by some other user's request, and you don't want your context available to some other random user!
If you need to maintain state on the server, you need to use any one of the normal ASP.NET solutions for maintaining server-side state.
Copyright (c) Marimer LLC