State management

[DKode]

Can anyone point me to a good location for state management
information. I am having to re-code a good portion of my login code to
properly manage persistent state. As it is right now, I was saving the
object(user) into the HttpContext.Current, but I find this does not
persist from page to page.

I am using FormsAuthentication and saving it to an encrypted cookie.
Can I maintain state like this or would it be ineffecient to store an
object in the users cookie. I would prefer to keep the object on the
server rather than pushing back and forth between client-server.

Thanks

DKode

 

[Kevin Spencer]

Hi DKode,

Since you're storing data that is specific to the user Session, I would
store it in SessionState. SessionState is a memory cache on the server.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Craig Deelsnyder]

Can anyone point me to a good location for state management
information. I am having to re-code a good portion of my login code to
properly manage persistent state. As it is right now, I was saving the
object(user) into the HttpContext.Current, but I find this does not
persist from page to page.

I am using FormsAuthentication and saving it to an encrypted cookie.
Can I maintain state like this or would it be ineffecient to store an
object in the users cookie. I would prefer to keep the object on the
server rather than pushing back and forth between client-server.

Thanks

DKode

Cookies are not good IMHO for storing state unless you absolutely need it
stored there for identification, etc. between visits...your instincts are
correct, server-side persistence is the usual approach (keeping
performance in mind as well). As you found out, context is valid for the
current thread/request only. Once the page is served, it's over with.
Session may be your likely bet, but read this to get the full scoop:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/DIforWC-CH05.asp

 

[Steve C. Orr [MVP, MCSD]]

I'd think you should store that in Session insted of Context.
Luckily the syntax is nearly identical.

 

[DKode]

is declaring a variable to the SessionState the same thing as doing:

Session["User"] = new User();

once i declare the session var, I grab it back out:

User u = (User)Session["User"]

lets say i make some changes:
u.UserID = 5655;

do I then need to save this back to the session when I am done working
with it like so:

Session["User"] = u;

I guess it comes down to if it is ref or val type.

thanks

 

[Steve C. Orr [MVP, MCSD]]

Yes, you should then put the modified value/object back into Session state.

 

[Ahmed Mahfouz]

is declaring a variable to the SessionState the same thing as doing:

Session["User"] = new User();

once i declare the session var, I grab it back out:

User u = (User)Session["User"]

lets say i make some changes:
u.UserID = 5655;

do I then need to save this back to the session when I am done working
with it like so:

Session["User"] = u;

I guess it comes down to if it is ref or val type.

thanks

guys, saving the user object to the session will eventually be a very
big performance set back on the server,I'd rather u'd just save the id
of the user in the session and not the whole object.