what are the alternatives of SESSION VARIABLES? [duplicate]
Asked Answered
D

4

7

What are the limitations of the session variable in developing large web application. Also what are the best alternatives of the session variables.

Please provide me the alternatives of SESSION VARIABLES

Digitoxin answered 31/7, 2013 at 10:1 Comment(1)
L
20

To understand the advantages of not using sessions, you have to understand how sessions work.

In the default setup,

  • sessions are identified by a cookie set in the user's browser and
  • the session data is stored in-memory on the webserver

When the user sends a request to the server, the session cookie is sent along. It contains an identifier which the server uses to locate that particular user's session data.

You can configure ASP.NET to

  • use query parameters instead of cookies to store the session identifier
  • store the session data in a database (having a central data store for session data is particularly important if you have multiple servers serving your site)

Now for the advantages of disabling session state:

  1. ASP.NET makes access to the session data thread-safe by serialising requests. This means that, when session state is enabled, ASP.NET refuses to serve concurrent requests from the same user. This is particularly an issue when the user's browser makes a lot of ajax requests. This problem can be mitigated by marking session state read-only for requests where you don't need to update it.
  2. When the request comes in, ASP.NET has to fetch the session data, and it has to write data back when the request ends. This may not be a big issue if session state is stored in-memory, but if data is stored in a central database, this can cause serious performance problems.

Needless to say, these issues are exacerbated by storing large amounts of data for a large number of users.

For more information see

  1. ASP.NET Session State Overview
  2. Fast, Scalable, and Secure Session State Management for Your Web Applications

(that last article is a bit dated, but still a good read).

Alternatives

  • If you can, avoid session state altogether.
  • If you absolutely must associate data with the user, use the mechanisms of HTTP and make the browser carry the data in a cookie or perhaps a query parameter (this is partly what the whole REST-movement is about).

Hope this helps.

Lubricity answered 31/7, 2013 at 12:20 Comment(1)
The MSDN Magazine link, to the September 2005 issue, is broken. Here is an archive.org version, also they provide a CHM download of the complete September 2005 issue, including your article.Sculpturesque
C
2

It depends upon the business logic of your application in some cases session may be the best choice , however there are lot of alternatives ,Session should be used if you are having different data for each request to your application ,you can post your data in hidden fields with your forms , but again ur question is a little bit of the track, You have to analyze your requirement than according to it you have to decide whether to use sessions or some other alternate solution , If I have to store id's of users than definitely I will go for sessions cause it will be different for each users , I would not keep very big data in session like keeping a dataset in session which few developers do . Then also questions comes if ur using session where u want to keep it in process or in server , if ur saving session in server it is very costly but in ssome scenarios its very useful .

Cyme answered 31/7, 2013 at 15:34 Comment(0)
C
1

Pros and Cons of Session Variables See Here

Chunky answered 31/7, 2013 at 10:21 Comment(1)
That post you linked to (and Saritha apparently copied from) is very old - it talks about classic ASP. But mostly it's still valid.Stenograph
H
0

Since data in session state is stored in server memory, it is not advisable to use session state when working with large sum of data. Session state variable stays in memory until you destroy it, so too many variables in the memory effect performance.

Session variables and cookies are synonymous. So if a user has set his browser not to accept any cookies, your Session variables won't work for that particular web surfer!

An instance of each session variable is created when a user visits the page, and these variables persist for 20 minutes AFTER the user leaves the page! (Actually, these variables persist until they "timeout". This timeout length is set by the web server administrator. I have seen sites that the variables will collapse in as little as 3 minutes, and others that persist for 10, and still others that persist for the default 20 minutes. ) So, if you put any large objects in the Session (such as ADO recordsets, connections, etc.), you are asking for serious trouble! As the number of visitors increase, your server will experience dramatic performance woes by placing large objects in the Session!

Houselights answered 31/7, 2013 at 10:5 Comment(4)
@saratha Did you type the all words in just 4 min's???? It's very amazing :: lol :pCleanly
@saritha what about its alternative (session variable)...Digitoxin
Session variables and cookies aren't synonymous. Your session is identified by a cookie, so you're right that cookies should be enabled for the default session implementation, but you can do a cookie-less session. In fact, cookies are an alternative to session variables. A really bad one, but still an alternative.Quartic
if you need to pass/store data in a page you can use ViewState as well.Houselights

© 2022 - 2024 — McMap. All rights reserved.