Now I'm going to use the SessionStateProvider class from the sample provided by Mircosoft into production .
In addition to clearing used session records from the blob, what
else do I need to take into consideration before using it in live site?
In the sample, SessionStateStoreData is serialized and stored in the blob. Instead, can I store in one of the columns of the table? What is the pros and cons of this approach?
While clearing the unnecessary session in the table and blob, what is the best and safest way to clear?
In my opinion the table based session state provider is not suitable to be used in production for a site. The hint is that Microsoft called it a sample. My main reason for this is that it doesn't deal with locking session data if there are several requests for the same session in a short period of time.
Related
I have to use a bulk amount of data through out the session for each user in MVC application (data is user specific)
Below are the two method I found it
Use a session object load the data into it and retrieve when ever needed
Create a XML file into the disk and retrieve the data when ever required
which one of the above is good for a web application?
If both are not good please let me know a convenient method.
I read about caching but that also take the memory concern as Session or not?
Please help me with simple example if anyone has gone through the same.
I will not go with any of the approaches you highlighted, both the approaches will give you problems and code modification will be required when you plan to scale you application and try to move to load balancer or web farm type of environment.
You should try to make your application as much stateless as possible.
You can store the data in database, if your tables are properly indexed it will not take much time to fetch the data (almost same as fetching data from a xml file).
If the data is not sensitive and you requires it in client side only, you can think of storing it into sessionStorage
We have a fairly busy distributed cloud based system that we want to introduce basic profiling into. Firstly we'd like to monitor web page render times and DB calls - we use EF and SQLServer.
The question is what is the best (performant & easy) way to record this information? My first thought is to store it in a DB, but would this cause a performance issue when a single page render may require multiple DB calls and hence, multiple inserts into the performance table.
Would it be better to store this information in memory only, or perhaps store in memory short term then batch persist to a DB later? Or is some other approach recommended?
If you simply send INSERT statements to the database without block-waiting to receive values of identity columns, it should be fairly lightweight for the web server.
If the database table does not have any keys, (or only a clustered key,) it should be fairly lightweight on the server, too.
This would certainly be the easiest approach, and would not take much to implement it and give it a try, so I would recommend that you check whether it covers your needs before trying anything else.
Is it a good idea to avoid state management techniques(session, cookies etc) in ASP.Net MVC 3.0?
If yes then is there any other alternatives available except TempData?
This would depend on your specific requirements. Session state and cookies for example are very different beasts.
If session state is a good fit to your requirements in WebForms then it's a good fit in MVC. There is no specific reason not to use it in MVC.
You basically only have 3 places you can store data, on the client (cookies/hidden values/query string), on the server (session/cache/static), in the database.
There is loads of documentation of the pros and cons of all these methods, a good starting place is:
http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
It depends.
Session and cookies were invented to solve some kind of problem, so they should be used to solve that problem.
TempData won't help much in replacing cookies - because cookies are saved on client side.
Also TempData is Session, distinction is that TempData is for redirection only. As long as TempData is quite usefull in redirection scenarios, you may wish to keep session to be enabled for these scenarios.
If you don't have session oriented scenarios (like object creation has multiple steps and after first step you can't save it to database yet), you can avoid using it, but in general it is not by itself evil.
I find that state is nicely maintained in a cache when implementing the repository pattern. In the MVC Futures project, there is also the Html.Serialize method which gives 'view state like' state storage.
http://mvccontrib.codeplex.com/
For information like items bound to a combobox that we were used to having maintained automatically for us in web forms, a good alternative here is to call off to a repository for the data. The repository maintains a reference to a cache (ideally through an interface you create like - ICache). The repository then caches this data based on for ex. the current users name, key whatever. Some prefer to have a service layer cache, but I feel by design a repository layer was meant for this.
Session is still used - if you must - it has its place. A lot of 'bad' surrounds the session, but if you need to store session specific information and your site isn't concerned with a large number of hits a day, then you can likely take the hit just fine.
TempData is great for storing status messages to show on the next request such as 'record saved successfully' so you don't lose it across the redirect and don't have to pass it on the querystring. Thats about the only thing I use it for although some use it to store data for rebinding on the next request.
IMO, the rules for session state in MVC are the same as the rules in WebForms: use it if you must, but keep your usage lightweight. If you truly have some data to track per user/session, there is no need to reinvent the wheel.
You can save your state in the database directly
Hi
I working on Asp .Net project(Web App).
I have to many values, properties and fields. In order to use them I need to save them in somewhere.(I know about Session, Application and Cookie).
application isn't good cuz it is same for all user's but session is better(I need these values in server-side). Also cookie isn't good and I won't use that for security problem.
Session is good but if I use session a lot I must pay for massive memory on Host-Server.
So is there any better place can hold them ?
Edit 1
For more Information recently I fetch these values from database (so I won't to save them in database). and also use Wcf service for get these values from database. I want to hold these values to use them (for example sending them for service-method to do something or do something visually in page).
Thanks All
As has been commented, there are many ways of implementing state management, depending on the amount of data your looking to persist, overall volume of traffic, hosting costs, maintainabilty, etc.
This MS link describes the pros and cons of some of the techniques.
Yes, Session is the best way to use. Actually its consumes the comparatively least memory of all while using the server side state management technique.
If the values are much higher than you can use to store those values in database with the sessionid as the key with them. So that it will consume some what less memory from the server.
A database could be a good idea. Maybe SQL Server Express or SQL Server Compact Edition
I'm building a web system and various clients will have alternate text for default instances throughout the site. One place is the main nav but there are others. The default may be "project" but they may want to call it "event".
I'm heading down the road of calling all the terminology settings (there's a list of about 15) and creating an ArrayList that has the id and either the default or their replacement as the items in the ArrayList.
I've also got a enum key list called TermKey that has the defaults and the corresponding ID number.
Throughout the code I'll reference TermKey.Project and then do one of these things that I see as options.
1-pull the text from the session (if the client has set it to "event" then the text "event" will be waiting for the call there)
2-pull the text from the database every time I need it.
3-pull the client's list each time a page loads.
Some thoughts on the impact each way or if there is a best practice for this sort of thing would be appreciated.
The session isn't the best place for this kind of information. While yes, it is user-bound, the session state is really a repository for user-bound, session-bound information. What you seem to have is information that really has a scope beyond session.
The best way to reflect this information is to use a custom ASP.NET Profile Provider. You would use it to expose properties for the information you need to expose, while the logic in the properties would handle setting the values to the appropriate values based on the user in your system (or, an anonymous user, if they are not authenticated).
In your case, you could cache the values and access the database as needed in the profile provider.
Then, this information is exposed through the Profile property on the HttpContext class (and through the Profile property on the HttpProfileBase class as well if you are using ASP.NET MVC).
Anyway you shouldn't call DB on every page just to get alternate text. I think it is fine to store them in session if there are not too many of them (per user)
The way I've done this in the past is to have a database type code table and then a client-specific translation table like this:
TABLE ObjectType
ObjectTypeCode
TABLE ClientObjectTypeTranslation
ClientId
ObjectTypeCode
OverrideDescription
This allows my code to always reference what I know (i.e. ObjectTypeCode) and I then join to the translation table on every query and display the override description where relevant.
Though, this may be overkill for your scenario.
Session is ok to do this if you want to persist across sessions (and it's not TOO much data). Another option would be cookies.
I'd recommend on session start, instantiate session vars in a User object property, then can reference, User.DefaultText
If this is specific to each user, you might as well use session. Don't overuse is (and only use it for small amounts of data).
Going to the database for each request can be overkill, especially if this data doesn't change often - it will be much faster to retrieve from local memory than from over the network.
Having said that, using session InProc will limit you to a single server and will not allow you to scale to a web farm.