As I recall SessionEnd does not fire reliably. If you are really planning to take action when a users session ends then you probably need to get more creative.
I keep information about the logged on user in my custom Principal object which is always available.
If you have other information (which is not user specific) like Version number then you need to add it to the ASP.Net cache or some read only object which you then cache. Since it is not user specific it does not belong in Session state. By using the cache, it is available at the application level. If oyu need it on both sides of the dataportal you can choose to either pass it as part of context or just re-fetch and re-cache it on the other side. Obviously things like cache expiration are going to be a big deal. You can either decide that a 20 minute cache expiration is acceptable or else you can go with more advanced strategies.
Joe
ajj3085:
Just out of curiosity, when does SessionEnd not fire reliably?
I guess the most common reason is that the user can close their browser window and the server won't know about it. I'm sure Google can come up with some more reasons. <g>
Joe
I have run into situations where that doesn't seem to happen, and I can't tell you why. I remember reading in some documentation that the Session_End event will not fire if nothing has been put into the Session object. Whether that's true or not, I can't say - I've never been able to reliably test it. But I will agree that Session_End is not the most reliable thing.
- Scott
Hi,
I've been storing all this information in Csla.ApplicationContext.ClientContext.. but it seems like this information is lost between requests. My first thought is to update my business layer to use Asp.Net Session to store the information if it detects its running under Asp.Net.
Is there another way I should do this? Is the ClientContext really lost between each Asp.Net request?
Yes, ClientContext is lost between page requests. Nothing in ApplicationContext survives a page transition, because neither the thread nor the HttpContext survive - and those are the two places CSLA can store values.
While Session might exist, a lot of web sites turn it off to avoid the overhead. So CSLA never assumes Session exists - though personally I use Session in most web apps I build.
You can read web dev books to get the various state management
options.
But this is the web architecture’s Achilles’ Heel,
never in the history of computing (and hopefully never again in the future)
will we stumble into such an ill-conceived technology… The way you have
to deal with state in the web illustrates just how much the web technologies
were NOT planned, but rather clumsily evolved…
Rocky
Copyright (c) Marimer LLC