Last post Feb 08, 2010 09:08 AM by atconway
Feb 08, 2010 05:51 AM|Haansi|LINK
Is it harful to use session variables to keep a database record ? In my snario I have 4/5 froms which fills an object. I need to open these forms in edit mode. It is generally said session variables should not be used for keeping data. I was thinking is
it not bad to call database again and again ? I am not going to pull a table but just a recod (having about 50 columns data in it)
What you advice ? using session or calling db again and again.
<input id="gwProxy" type="hidden"><input onclick="jsCall();" id="jsProxy" type="hidden">
Feb 08, 2010 07:41 AM|XIII|LINK
to measure is to know.
How many concurrent users will you be having? How big's the data? You stated something like 50 columns but 50 columns of ntext or varchar(15) makes a difference.
Do you need to keep everything in Session of that record? I guess that you're going for some wizard like approach so you could keep the primary id of the record in session and retrieve the data dedicated to one page of the wizard from the database and not
perform a select * from tableX.
Feb 08, 2010 09:08 AM|atconway|LINK
Is it harful to use session variables to keep a database record ?
Generically speaking, not at all. Session state is secure and the variables are stored in memory on the server. So that answers the 'harmful' or reference maybe to security. The vulnerability with session variables is if the ASP.NET worker recycles or
the server is rebooted, the variables are lost. However there are options for storing your session variables in an alternate mode like 'StateServer' or 'SQLServer' which will persist the afore mentioned issues, but they each have there prerequisites
as well. To read up more on this, take a look at the following:
ASP.NET Session state:
If you want to read up on Session in general to help you getting a better understanding of its inner workings, than read through this which will help you make informed decisions on using Session State:
ASP.NET Session State Overview:
As far as calling SQLServer over and over; I would initially opt for using a Session variable to hold the object that was built up from the single call to the database. As mentioned in the last post, this suggestion could change if you have
a site with 1000 concurrent users, but many times this is not the case. ASP.NET does have connection pooling built in to help with repeat database calls which is good news if you do end up deciding to make the repeated database calls, but just based on what
you mentioned, I would probably use a Session variable to hold that data.