Sessions: A theoretical question

  • Thread starter Thread starter Ron M. Newman
  • Start date Start date
R

Ron M. Newman

Hi,

How do you maintain sessions (that contain data) in ASP.NET applications?

1) In memory on the web-server? in this case how do you handle multiple
requests from the same session which may be routed to different machines via
a load balancer?

2) Is this database? If so, do you have to fetch a record within every
request? how does his affect performance?

Or perhaps there's a third way I'm missing here?

Thanks !
 
Through the session object ;-).
1) No, client side. Also, You won't have any problems with load balancing.
2) No

You can store data queries in DataTables or DataSets or any other .NET
object in Session state but you don't want to get crazy with itj b/c it can
hinder performance.

Also, you can store state in the database but it's not a perfect analogy.
You can use a database variable to compare against and call session end..
but that isn't really using a database.
 
If you use Session on the server then you must require "sticky" sessions for
the load balancer.
If you use a DB for session data you can use any server (no more sticky
sessions) but you get a performance hit in reading writing to the DB. But
you gain the above plus no loss of data if a web server goes down.
 
???
Joe Fallon said:
If you use Session on the server then you must require "sticky" sessions for
the load balancer.
If you use a DB for session data you can use any server (no more sticky
sessions) but you get a performance hit in reading writing to the DB. But
you gain the above plus no loss of data if a web server goes down.
Click to expand...
 
Hi Joe,
If you use a DB for session data you can use any server (no more sticky
sessions) but you get a performance hit in reading writing to the DB. But
you gain the above plus no loss of data if a web server goes down.
Click to expand...

Because you are writing about a non mirrored server, is this also the right
solution when the SQL server goes down?

:-)

Cor
 
Joe is right. Storing session automagically in db is sweet because you
don't have to write any db access code for state management. And it is an
easy configuration-only upgrade from in-memory session.

Brad Williams
 
No, I was saying that Joe is right. ;) Asp.net session held in memory of
web server does not work in a farm (without router enforcing session
affinity to web heads, as Joe said), but asp.net session can be easily
reconfigured to store to a central db or dedicated server.

Brad Williams
 
Hey Cor,
Who mentioned a non-mirrored SQL Server? <g>

That would be a pretty dumb configuration wouldn't it?
 
Brad,
Thanks for the support.

It was just a piece of info for one of many ways to handle this issue.
I don't profess to be an expert on it but I think everything I said was
true.
 
Hi Joe,
It was just a piece of info for one of many ways to handle this issue.
I don't profess to be an expert on it but I think everything I said was
Click to expand...
true.

I did not say that it was not, however Bill (William) did not say it in a
much other way and you connected the message to the one from Billl and I did
not see big differences

The message from Bill was in my opinion more in the style from, you could do
and yours was more in the style from you should do.

And because he sand that message with that ??? I did support him a little
bit, which I probably would have done to you in the same situation too.

That was the only reason of my message.

:-)

Cor
 
Back
Top