I was considering using <sessionState mode="InProc" timeout="45" /> because some users are repeatedly logging in, and I would like to save them some time. However, before I add this to my web.config file, I wanted to make sure there would be no side affects.
I read up on sessionState versions, although I already am fairly aware of what goes on, I was curious to know what the default setting for an asp.net mvc 3 application was as there is no defined sessionState inside of my system.web at this time.
I know that the application has access to Session["key"] without the declaration, although I try to avoid putting that type of load on the Session. I would assume that there is a setting in IIS 7 which my application is inheriting (This application is on a shared hosting environment).
I understand that there could be issues if I was using a dedicated database or server for the Session, but this is just a basic setup as far as that goes, nothing fancy.
Is there a default sessionState for asp.net mvc 3? Is it just being inherited? Will there be side affects from overriding it in my web.config if it is defined elsewhere in IIS?
As of now the default Timeout = 20 minutes.
These are the default values for .Net Framework 4. I think they don't change because of MVC 3.
The accepted answer is correct, but possibly the OP is actually meaning to ask about authentication timeout which would be 30 minutes.
I know this is old but though it important to clarify that session state has nothing to do with authentication. The OP does not state what form of authentication is in use. Assuming Forms Authentication, then the default timeout for that is 30 minutes and is controlled in the <authentication...<forms element in web.config. I have found it best to have your authentication timeout set to less than your session timeout when using in-proc session. I tend to use out of process session as a preference, as it preserves session data from app-pool recycles.
Related
I am using ABP framework with MVC 5 and deployed into Azure. I have listed few session related questions below.
I used HttpContext.Current.Session in WebMpa project and AbpSession in Application services, but unable to get the data from AbpSession using HttpContext.Current.Session in WebMpa project, both are saving data in different place?
Am using static helper class and static property to Get/Set HttpContext.Current.Session value, if i want to remove the HttpContext.Current.Session any easiest way is available(with minimal code change), it could be better if we can get AbpSession from that static class?
I want to alert users 20 secs prior to session expired, is there any build in option available in ABP?
If I enable to Redis Cache implementation in my application, Cache, HttpContext.Current.Session, AbpSession and TempData will works without any issues and all should Get/Set values from Redis datasource?
AbpSession is not extending HttpContext.Current.Session. So the answer is yes you cannot share data btw AbpSession and Session.
Don't use static for injectable types. bad practise!
There's no built-in function for that. You can achieve this with a javascript function. When you finish a request, start timer. You know the session timeout duration. So when it reaches to 20secs, show an alert window to continue session. If answer is Yes then make a new request to slide session.
No! As i stated, Session and AbpSession is totally different things and you cannot share btw them.
PS: AbpSession stores claims. And it's extendable. So you can store any item in AbpSession. See the link to understand how to extend AbpSession https://gist.github.com/hikalkan/67469e05475c2d18cb88
I'm building a profile page with update form. After submitting the form with new data and several page refreshes I see sometime new and sometimes old data. It depends on thread handling current request. One thread contains new data and another one old. NHibernate is configured using ThreadStaticSessionContext and NoCacheProvider. In Autofac UserStore, OwinContext.Authentication and UserManager are configured as InstancePerRequest.
I tried to change ThreadStaticSessionContext to CallSessionContext and it started working normally. So the question is: why it works(ThreadStaticSessionContext is preferable for multithread apps) and what negative effects can it bring?
Thanks!
ThreadStaticSessionContext is for long running processes such as windows services or windows apps. For web applications you want to be implementing Session Per Request. This is what the WebSessionContext is for.
I actually don't use any of the contexts and just wire it up myself. See my answer here for an example.
I've an MVC3 web app which uses the default "in process" session. I've the PRG pattern in place - that is while postback if my modelstate is invalid I store the model in TempData and redirect to the original get action. In the get action I fetch the model data (if it exists) and send to the view. I believe this is one of the basic aspects of MVC.
I've learned that TempData in background is a session variable which
is used in the PRG transition. What I need to know is whether it is
possible to have a conflict or cross refrencing - if I use something
like TempData["model"] in two pages and access the pages
simultaneously. Would that overwrite the common data in
TempData["model"] or is it safe if I use the same tempdata names in
two different pages.
And does it conflict with Session["model"] kind of data? I'm facing some unexpected session data corruption - possibly due to my internal code that resets the session data or something else. Is it possible that session data can corrupt partially? I mean Session["data1"] is ok but Session["data2"] is gone?
My users often use the web app for a long duration causing session timeout. I tried for the ASP.Net session state service for session but that caused performance issues because I store some heavy objects (via serialization) in session. So finally I was back to the original default in proces mode.
Pls share if you've had any similar experiences.
TempData by default uses SessionState and access to SessionState is by default exclusive. So, if you do two concurrent reuquests, one will have to wait for the other to release the SessionState lock.
TempData does not interfere with using SessionState directly.
As SessionState by default uses in-proc, it can be invalidated almost anytime.
You might want to have a look at http://brockallen.com/2012/06/11/cookie-based-tempdata-provider/
We have an application with ASP and ASP.NET. We use StateStitch for the session sharing and stateserver setup for persisting (caching) sessions.
Now we want to implement High Availability and distributed caching, using AppFabric.
Only problem is: AppFabric requires <sessionState mode="custom"> and StateStitch requires <...mode="StateServer"> (tag in web.config)
Do any of you have any idea on how to go forward from here? Can't seem to implement AppFabric as //typeof(StateServer) and can't seem to make StateStitch accept custom setup.
Any thoughts, preferably utilizing one/both of the above mentioned techs...
Looking for the free solution :-)
Fixed it.
A hardcoded declaration in StateStitch, validated on StateServer and failed on Custom.
Solution: Added 'Custom' to the
If (Mode.StateServer || Mode.Custom) { Validated = true; }
I'm looking at using Subsonic with a multi-tenant ASP.net web application. There are multiple DB's (one per client/instance). The user logs in with a domain suffix to their username (e.g. user#tenant1, user#tenant2).
The custom membership provider will then determine which database a user is using, and authenticate against it. All user-initiated calls in the webapp will be wrapped in a SharedDbConnectionScope call, however I have a question regarding caching subsonic items.
Basically each instance will have a few records that rarely change (search options/configurations). I would like to read these in the Application_Start event, and cache them into the ApplicationState.
In the Application_Start event, it would loop over each client database, use a SharedDbConnectionScope to connect to each DB, and create these cached records (e.g. Application('tenant1_search_obj') = subsonic_object
When a user loads the search page, it would then check what domain a user is in, and then retreive that search option from the cache.
Is this feasible? I'm just concerned that if I cache an object, when I retrieve it from the application cache it won't know what connection its using, and might possibly pull in the wrong data.
I'd like to avoid putting this in the session object if possible.
it's possible, but probably not a good idea since it doesn't scale at all - you're going to pop a new connection for every single client whether they show up or not.
Maybe your best bet is to "lazy load" the setting - first hit on the search page loads the config into the cache or Application settings and there it stays.
Other than that - to answer your question it is possible. If you're using SubSonic 3, just create a new provider on the fly using ProviderFactory.GetProvider(connectionString, "System.Data.SqlClient") and then execute your stuff against it.
For SubSonic 2 - SharedConnectionScope is what you want.