Saturday, April 10, 2010 1:48 PM
I'm using Velocity for Session State and had 3 questions:
1) Is there a way to have my application get notified when a session expires, so that I can perform some housekeeping?
2) I'm using ClusterConfig.xml with a named Session cache, what config settings should I use to properly set up and support idle-time expirations?
3) Is there a way that I can expire a users session on demand (e.g. to support logout)?
Monday, April 26, 2010 9:56 AM
- There is no way currently to get notified when using a session store provider when your data expires . We just pick the expiry time period from the session timeout property . Hence you know the value you have specified ( or the feault value of the property ) and hence can take appropriate actions . if you really want a notification then you will need to use the cache directly instead of using the session store provider .
- We do not have idle-time expirations . We do not support a sliding window expiration . For example , you have set an object timeout to be 20 minutes . Then after 18 minutes you read it . But after 2 min it will expire . It will not live for another 20 minutes after the read .
- You may call HttpSessionState.Abondon to clear the user's session on demand .
Harish Kumar Agarwal
Tuesday, April 27, 2010 9:41 AM
1) Session expiry notification is something related to (or in the contorl of) ASP.Net session. Please go through http://aspalliance.com/520
2) Since your question is in the context of session state, when you use the session state provider, the session object is stored in the cache with a timeout equal to the ASP.Net session timeout. Each time the session is accessed, the timeout of the session object in the cache is also reset to the session timeout. It is made sure that the session object expires from the cache only when the ASP.Net session times-out. I hope this is what you are looking for.
Thursday, April 29, 2010 1:52 PM
So if I'm understanding this correctly, by using the SessionStore provider with Velocity I get distributed session cache as opposed to per web server session cache, which is what I'm looking for as I'm using MVC in a web farm and do not have affinity to any one web server. Correct? Does this mean I should keep all my web servers synched up with their sessionstate timeout setting? Not sure what happens if the web servers have different timeout settings?
Additionally, I should use the HttpSessionState class to detect timeouts.
That specifying a named cache within the SessionStore really isn't necessary as there is no configuration to set other than what goes in the SessionState config info in web.config. What benefit is their to using a named cache for the SessionStore?
Friday, April 30, 2010 9:08 AM
By using AppFabric Cache ( aka Velocity ) you get a distributed cache which can be used to store your session store data too . By just modifying web.config the data gets stored in the cache . There are two advantages of storing it in AppFabric Cache : Performance and Scalability .
We just pick the expiry time period from the session timeout property or the default value if nothing is specified . This way you are free to choose how to sync up your web servers .
By specifying a named cache in the web.config you ensure that the data from that session goes to a particular named cache only and hence is isolated from all other named caches . You can set up one AppFabric cluster and store that data from each web server into a different named cache .
Can you explain your scenario in greater depth so that we may recommend whether AppFabric Cache will help you solve your issues .
Harish Kumar Agarwal
Friday, April 30, 2010 4:56 PM
I believe Velocity does solve my needs. I have an ASP.NET MVC based web app that runs in a web farm, but has no affinity to any 1 web server. So requests can go to any web server in the farm. But I want to maintain session state when processing each request, so all the web servers should use Velocity to retrieve the users global session on each request (meaning the session is shared by all the web servers). This is what I believe Velocity gives me.
Whan I specify a named cache for a session cache, there are options to configure it and I was uncertain what to specify when I'm only using the cache for Session. So the question was what settings belong in the ClusterConfig for a named cache only being used to store Sessions?
A second question was to be able to detect when a session ends. I'm accustomed to using Global.ascx with Session_End, but that does not get invoked when a Session expires (although Session_Start does so maybe this is a bug in Velocity???). The alternative that you gave was to keep calling HttpSessionState to determine it, but this is less desireable.
The third question you've answered which is to call HttpSessionState.Abondon to end a session.
Monday, May 03, 2010 5:02 AM
The session state is available to all web servers or shared with all web servers as long as all the application on the web servers has the same web AppName.
You need not change anything in the ClusterConfig manually. If you wish to use a name for the cache (say MyCache) where your session state to be stored then create a cache using New-Cache powershel cmdlet then provide the same name in the Web.Config file so that the Velocity session store provider uses that named cache (MyCache) while storing the session state. See example below.
"DataCacheSessionStoreProvider" type="Microsoft.Data.Caching.DataCacheSessionStoreProvider, ClientLibrary" cacheName="MyCache"/>
Again Session_start and Session_end events are under the control of ASP.Net not Velocity. Can you please provide more details here?
Monday, May 03, 2010 1:35 PM
With regards to the Session_start and Session_end details... I'm developing in VS 2010 using Velocity as the Session store provider and I'm running a simple test with an MVC based web app with a session timeout set to 1 minute. I set debug breakpoints in the Session_start and Session_end methods in Global.ascx. I hit the break point for the session start, but the Session end is never fired. However, after a minute the session is actually expired, just no Session_end event is triggered. My assumption is that this must be some kind of interaction problem between ASP.NET and Velocity...
Thursday, May 13, 2010 6:01 AM
Not all sesion providers support this Session_end events. Typically out-of-proc session providers like SqlSessionStateStore, OutOfProcSessionStateStore - don't support Session_end events. Session provider shipped with App-fabric caching(earlier velocity) also don't support this event. You can find more information at the documentation for session-state events:
- Marked As Answer by LightningStrikes Monday, May 17, 2010 3:23 PM