Cookie and Webpage Question

[Mike]

Hi,

Upon login into my application I stored user data (userid, ...) in a cookie
to be used throughout the application. One particular form is very
complicated that uses AJAX and many AJAX postbacks it needs data from that
cookie. Is it bad practice to keep opening that cookie to get data each
request or should I store it (hidden fields ...)? In the future this
application will be on multiple webservers (replicated with a load balancer
in front) so my options are limited. I chose not to go with storing session
state in SQL DB because of performance issues. I have a small amount of
data that I need to store per session which can be stored in a cookie and it
is a simple solution. Any suggestions?

Thanks

[Mark Rae]

"Mike" <mi***@mike.comwrote in message
news:Oj**************@TK2MSFTNGP04.phx.gbl...

Upon login into my application I stored user data (userid, ...) in a
cookie to be used throughout the application.

Hmm...

One particular form is very complicated that uses AJAX and many AJAX
postbacks it needs data from that cookie. Is it bad practice to keep
opening that cookie to get data each request or should I store it (hidden
fields ...)?

Why can't you use use ViewState? Read the cookie when the page first loads
and cache it in ViewState.

In the future this application will be on multiple webservers (replicated
with a load balancer in front) so my options are limited.

In what way(s) are your options limited...? You're talking about non-sticky
sessions...? There are plenty of solutions for that...

http://www.microsoft.com/technet/arc....mspx?mfr=true
http://www.microsoft.com/technet/pro.../webclust.mspx
http://technet2.microsoft.com/Window....mspx?mfr=true

I chose not to go with storing session state in SQL DB because of
performance issues.

Performance issues...?

I have a small amount of data that I need to store per session which can
be stored in a cookie and it is a simple solution.

Presumably this is a public website? What are you going to do if people have
disabled cookes...?

Any suggestions?

Use sticky sessions.

[Mike]

Mark,

Thanks for the post. I am assuming that what you mean by sticky sessions is
use ASP.Net Session state InProc mode. This method is not scalable and I do
not want to force my user to access the same webserver (it kind of defeats
the purpose). You do make a good point about cookies and probably should
use a different method. I really do not want to store session state in a
SQL DB because:

1) I am not storing a lot of data
2) Not scalable
3) Performance

I will continue to look into session state.

Thanks

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

"Mike" <mi***@mike.comwrote in message
news:Oj**************@TK2MSFTNGP04.phx.gbl...

>Upon login into my application I stored user data (userid, ...) in a
cookie to be used throughout the application.

Hmm...

>One particular form is very complicated that uses AJAX and many AJAX
postbacks it needs data from that cookie. Is it bad practice to keep
opening that cookie to get data each request or should I store it (hidden
fields ...)?

Why can't you use use ViewState? Read the cookie when the page first loads
and cache it in ViewState.

>In the future this application will be on multiple webservers (replicated
with a load balancer in front) so my options are limited.

In what way(s) are your options limited...? You're talking about
non-sticky sessions...? There are plenty of solutions for that...

http://www.microsoft.com/technet/arc....mspx?mfr=true
http://www.microsoft.com/technet/pro.../webclust.mspx
http://technet2.microsoft.com/Window....mspx?mfr=true

>I chose not to go with storing session state in SQL DB because of
performance issues.

Performance issues...?

>I have a small amount of data that I need to store per session which can
be stored in a cookie and it is a simple solution.

Presumably this is a public website? What are you going to do if people
have disabled cookes...?

>Any suggestions?

Use sticky sessions.

[Mark Rae]

"Mike" <mi***@mike.comwrote in message
news:Oa**************@TK2MSFTNGP02.phx.gbl...

Thanks for the post. I am assuming that what you mean by sticky sessions
is use ASP.Net Session state InProc mode.

No - check the links I posted previously.

I do not want to force my user to access the same webserver

It's not user-specific - it's session-specific i.e. user connects, a session
is created and that session is handled by the same webserver in the cluster
/ farm until it is torn down, but next time the user connects, they may very
well get routed to a different webserver in the cluster / farm...

(it kind of defeats the purpose).

How so...?

I really do not want to store session state in a SQL DB because:

1) I am not storing a lot of data

Irrelevant.

2) Not scalable

Not true.

3) Performance

Not true.