We have several wizard style form applications on our website where we capture information from the user on each page and then submit to a backend process using a web service.
Unfortunately we can't submit the information in chunks during each form submission so we have to store it the users session until the end of the process and submit it all at the same time.
Is the amount of server memory/sql server disk space the only constraint on how much I can store in users sessions or is there something else I need to consider?
Edit: The site is built on ASP.NET web forms.
Assuming the information is not sensitive then you could store the information in a cookie which would reduce the amount of information required to be stored server side. This would also allow you to access the information via JavaScript.
Alternatively you could use the viewstate to store the information although this can lead to large amounts of data being sent between the server and the client and not my preferred solution.
The amount of session information you should store varies wildly depending on the application, number of expected users, server specification etc. To give a more accurate answer would require more information :)
Finally, assuming that the information collected throughout the process is not required from page to page then you could store all the information in a database table and only store the records unique id in the session. As each page is submitted the db record is updated and then on the final page all the information is retrieved and submitted. This is not an idea solution if you need to retrieve previous information on each subsequent page due to the number of db reads required.
You could also have 1 asp page with the entire html form, and hide parts of it until the user fill and "submits" the visible part...
then simply hide the part that is filled out and show the next part of the form...
This would be extremely easy in the .NET framework, use panels for each "wizard step" and add loggic when to display and hide each panel.
you will then have all the data on one page.
If you use a traditional HTTP model (i.e. don't use runat="server") you can post the data to another asp page and place the posted data into hidden form elements, you can do this for however many pages you need thus avoiding placing anything in a session variable.
Since it is problematic from performance point of view to store large amounts of data in user Session object, ASP.Net provides some other workarounds on top of what is mentioned in the posts above. ASP.NET Profile Provider allows you to persist session related information in a database. You can also use Session State Server which uses a separate server to store all Session information. Both of these situations take into account if you need to use clusters or load balancers, the servers can still recognize the session information across different servers. If you store information in the Http Session object, you run into the problem that one user must always go to the same server for that session.
Session, viewstate, database. These are all slow but will get the job done.
Hidden form fields is the answer I like best.
There are other ways to persist state. Cookies, popup window, frameset or iframes.
Related
Can any one help me in explaining the detailed and proper use of ASP.NET Sessions.
i read many web portals and blogs but i do not understand how to and where to use the sessions.
we create many sessions on page, for login, transfering some values from one page to another. but what is its impact on multiple users like more than 10000 users accessing the website, server transfer rate. memory storage, etc.
This may help many beginners, and also experienced person to properly use sessions in their project.
Any help is appreciated.
This is roughly how it works:
When the user visits your webpage, a session ID is set in a cookie in the user's browser. Each time the browser sends a request to the server, the browser will pass the cookie containing the session ID to the server. This allows the server to recognize the user and associate data with the user across multiple page requests (you can use sessions without cookies if you want to).
The server will by default store this data in memory. However, if multiple webservers are running the application and serving the same user, they will all need to know about the user's session data. Thus, you can configure your application to store session data using the "ASP.NET State Server" Windows service, or you can store the data in a SQL database (or you can write your own Session State Provider and store the data wherever you like). Moreover, storing the session data in memory is obviously a bad choice if you are worried your machine might crash (that obviously should worry you).
As for the "proper and detailed" use of ASP.NET sessions it is hard to say - it depends on what you are trying to achieve.
If you can help it, you should store only small amounts of data in sessions, as the combined sessions of all users visiting your website may take up quite a lot of space. Moreover, if you are using the ASP.NET State Server or the SQL Server session state stores the data you store needs to be serialized and deserialized, which will take a non-trivial amount of time for data of non-trivial size.
If what you are planning to store isn't confidential, an alternative approach might be to store the data in a cookie. That way your server will not have to worry about storing the data at all. This way you are trading memory (or disk space or whatever storage mechanism you choose) for bandwidth, as the cookie will now be part of the payload for every request.
Here's the question scenario:
Suppose you have a multiple-page ASP.NET web site with the following
requirements:
User-specific data for the currently logged in user is loaded and is required on each individual page of the application during a user's session.
The application itself only allows a certain number of users to be logged in at one time.
The next time a specific user logs in, the user should be returned to the last page visited.
Given this information, briefly describe how you would use ASP.NET to manage the state of the application to meet these needs?
Here's my thoughts and reasons. Please provide yours.
User-specific data for the currently
logged in user is loaded and is
required on each individual page of
the application during a user's
session.
This is suggesting to me that the interviewer is looking to see if I would suggest using Master pages as a way to provide a common approach to displaying the same thing on every page.
The application itself only allows a
certain number of users to be logged
in at one time.
Could the sought response be that, because scaling isn't an issue due to the limited number of users, that it is OK to put this information in the Session object for performance reasons or is this a trap and some of approach is better?
The next time a specific user logs in,
the user should be returned to the
last page visited
A cookie seems the best approach to track the last page access, since this doesn't seem to be critical information.
Please tell me how you would handle these question if you wanted to make the best impression
Feel free to provide input or comment an any line item.
Thanks!
As far as (3) is concerned, consider a shared PC. User A logs into a website using their site based user name/password. Does a whole load of work and shuts down the browser. USer B then comes along and on the same PC logs into the same site using their details. However, they will get the cookie from User A and be redirected to the last page they saw. This happens because Cookies are tied to the browser / OS user, where as you are potentially applying the site security separately in the application.
In this situation you would either need to put the user name into the cookie (encrypted) or use a server side method to store the location
Here are my thoughts:
They might be looking for Master Pages, but my first thought here was whether you're going to cache this user data, so you're not making a database query every time they hit a new page. To really impress them, you might mention partial caching techniques so that the repetitive portions of the page don't even need to be re-rendered with each page load.
I think you're right: they're helping you to conclude that the session state is an appropriate place to cache the user data. Just be sure you ask the appropriate questions, like "How many users?", and "How much data per user?"
The cached data could be used to keep track of the last-requested page, and when the user's session expires, you could save this data into a database table to be retrieved next time they log in.
That third item is awfully tricky. What if the user was last looking at an object that has since been deleted? What would be the intended behavior if a user logged in from one computer, did some work, and then logged in simultaneously from another computer or browser? I'd be sure to ask these kinds of questions, not least to show that I understand the implications of a requirement like this. If their responses lead you to believe that they're looking for a simple solution, go with the simple solution. Otherwise, tweak your response to be only as complicated as necessary.
Just a small thought.. If the system are running in a "Farmed" environment the Session data can be cleared and need to be handled some way.
http://www.beansoftware.com/ASP.NET-Tutorials/Store-Session-State-Server.aspx
My question is how to best handle temporary data for an session. The scenario is similar to a shopping cart or like a bet slip. While the user is navigating the site and adding items with unique ID's. I'm only interested in the data collected this way if the user wants to commit it.
I'm developing in ASP .Net 3.5 with jQuery,JSON and a MS SQL DB.
As I see it there are a few possible ways to do this.
Perform a full post back to the server. Store every selections, update page controls accordingly.
Send selections via a Ajax request back to the server and update displaying control.
Build all functionality in JavaScript and store all values in a session cookie. Nothing being sent to server until user choose to commit.
I really want to consider performance here but I don't want to end up with 1000's of lines of JavaScript code..
Any suggestions of the best implementation with pro's and con's?
Cheers,
Stefan
Storing things in a session cookie is not a good idea, because that will be sent back to the server with every request. If you could find a way to store the state on the client without using a cookie, then you might have a viable client-centric option, but i can't think of anything portable off the top of my head. There are things in HTML5 and Flash that can do it, but you don't want to go there - yet, in the case of the former, and at all, in the case of the latter.
I'd use AJAX to post back to the server (with graceful degradation to a full post for browsers that can't handle that), then store the information in volatile memory there - ie not in the database. Write it to the database only when you need to. This is very easy to do in Java (you can associate information with the session), so i assume ASP.net has some way to do it too.
All three possibilities look good to me. The question, however, is: how much traffic do you expect?
Each of the options you presented suits better to a given scenario. Let's say you will have A LOT (thousand of thousands) users and not a lot of hardware available then you should probably try to minimize the number of requests to your app and store data in the client as much as possible before sending it to the server.
If it is smaller application then using Session or some other central database storage would be fine.
It all depends on your requirements.
My Client has an application that is built in ASP.NET (c#) that makes use of a lot of ExtJS controls.
I need to enable the application to save every thing on the entry screen to a temporary storage mechanism and when necessary restore it.
The scenorio is the user has captured some data to a specific screen but is unable to continue and then there session expires.
If this happens and the user then logs in, it needs to restore there data/
Are there any good ideas I can investigate this type of thing.
I would like to make it as simple and robust as possible.
Thanks
Sure, you can always store data on disk IO or a database and tie the information to their application user ID. That's one way, and have a button to save the incomplete form. Are you looking to save on the fly (auto-save)?
Could you provide more details?
There are 6 techniques to manage states in ASP.NET 3.5 (as far as I know).
(1) View State
(2) Cross Page Posting
(3) Query String
(4) Session State
(5) Application State
(6) Cookies
Can anyone give me some appropriate examples of situations where I should use these techniques?
For example:
(*) Session State: Personalization, Buy Cart, etc.
(*) Cookies: Saving User Credentials, etc.
There's a lot of factors that can influence this, so I won't comment on all of them. But here are a few pointers:
ViewState - This is useful when you'll be posting back to the same page frequently (something you're practically forced into doing by ASP.Net Webforms). How useful it is exactly changes depending on what kind of app you're building. For public internet sites, it should be used very sparingly. You may even want to turn it off by default. For local intranet sites, it's a great tool — especially for the fewer, heavier, webforms pages.
Query String - Use this to store state that you need to allow the user to bookmark a page or process and come back to much later. Even then, you might want to keep it down to some kind of hash that you can use as a key in a database lookup to avoid a really huge url (though hashes have their own problems). Also, a lot of users like to fiddle with your query string directly, so it can be dangerous to put too much here. It's easy to accidentally expose data to users who aren't supposed to see it this way.
Application State - Remember that this is shared by all users, so use appropriately. Things like view counts can go here.
Cookies - Don't use cookies to store user credentials. They're just plain unencrypted text files. Use cookies to store a key into the session (even here you can and should now use cookie-less sessions) and simple personalization settings that will be specific to that user and browser. For example, my monitor size at work is different from home, and so putting display size/layout settings into a cookie is nice because the settings stick for each computer, but it isn't going to compromise my security any if someone else reads that information.
Now I want to highlight this concept from the "Query String" section:
you might want to keep it down to some kind of hash that you can use as a key in a database lookup
Again, hashes have their own problems, but I want to point out that several items on my list talk (including Query String) about uploading data from the client web browser to the web server: ViewState, Query String, Cookie, and Cross-Page Post. You want to minimize the data that you move from client to server. This concept applies to all of these, and for several reasons:
Pulling data from the client is slow for public internet sites. Even broadband connections typically cripple the bandwidth available for upload. 512Kpbs (still a typical broadband upload rate in many areas) is nothing when compared to the Gigabit Ethernet (or faster) connection that likely sits between your database and your web server. As much as you might think of a database query as slow (and it is), it's still likely a much better way to go than waiting for the same data to arrive from the client.
Keeping the data on the server is cheaper, because you don't pay for the bandwidth required to push it to or from the client, and bandwidth often costs as much or more than your server hardware.
It's more secure, because if done right even when a client's computer or connection is compromised all the hacker has access to initially is a hash key that likely expires by the time he can decrypt it. Of course, if done wrong he can use that key directly immediately, so you still need to be careful.
So for most things, what I recommend is to start out by keeping a database key in the Session and then have code to easily pull what you need from a database based on that key. As you experience bottlenecks, profile to find out where they are and start caching those pages or controls, or keep that data/query result in the session directly.
State management option
View state:
Use when you need to store small amounts of information for a page that will post back to itself. Using the ViewState property provides functionality with basic security.
Control state:
Use when you need to store small amounts of state information for a control between round trips to the server.
Hidden fields:
Use when you need to store small amounts of information for a page that will post back to itself or to another page, and when security is not an issue.
You can use a hidden field only on pages that are submitted to the server.
Cookies:
Use when you need to store small amounts of information on the client and security is not an issue.
Query string:
Use when you are transferring small amounts of information from one page to another and security is not an issue.
You can use query strings only if you are requesting the same page, or another page via a link.
Server Side Management Options
Application state
Use when you are storing infrequently changed, global information that is used by many users, and security is not an issue. Do not store large quantities of information in application state.
Session state
Use when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.
Profile properties
Use when you are storing user-specific information that needs to be persisted after the user session is expired and needs to be retrieved again on subsequent visits to your application.
Database support
Use when you are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.
Not sure if you mean the Cache object by Application State.
The Cache object is a great way to manage application wide state, e.g. to record source and count access to your website (to prevent DDOS attacks for example).
(3) Query String
(4) Session State
(5) Application State
(6) Cookies
1. Viewstate
Disclaimer: Use as little as possible. Good point is to always have each state reachable by an url, if possible.
F.e. Paging should use the URL (so /url/?p=2 instead of storing the page in Viewstate)
Use to persist control state between page-cycles.
F.e. Store the selected item in a checkbox, so you can determine whether it has changed.
2. Cross Page Posting
Don't. See the disclaimer for viewstate. Use the URL for this, or store the data in a session / cookie / profile if loads of properties need to be kept around.
Major downside of CPP is that the user cannot use the 'Back' and 'Forward' buttons in it's webbrowser. When a user clicks the back button it wants to undo everything on that page and retry the last one. When using CPP to click them through a wizard; this behavior is not possible without a lot of 'Are you sure you want to resend blablablabl'.
3. Query String
Use alot. Every visible state that a page could reach should be accessible by URL. People with screenreaders will thank you for this. And by using the query string there is no need to use javascript-only solutions.
/url/?page=2 // when doing paging, don't use postback for this
/url/?tab=advanced-search // when having tabs on top of your page
etc.
4. Session state
Use this for short-living objects, that only make sense this time the visitor visits your site. For example:
Which step of a certain wizard was reached
Pages a user had visited before
Small objects you want to put in cache, but that are user-bound
Don't use sessions but profiles for things like:
Preferences
Selected language
Because those things also make sense the next time the user visits your site.
5. Application state
Never. Use ASP.NET cache, or memcached, or any caching framework for this.
6. Cookies
Session ID, Profile ID for authenticated users; user preferences for anonymous users (everything listed in the second list under 4.).