Sessions: A theoretical question

[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 !

 

[William Ryan eMVP]

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.

 

[Joe Fallon]

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.

 

[William Ryan eMVP]

???

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.

 

[Cor]

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.

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



Cor

 

[Brad Williams]

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

 

[Cor]

Hi Brad,

Are you saying with that that Bill (William) is wrong?

Cor

 

[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

 

[Joe Fallon]

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

That would be a pretty dumb configuration wouldn't it?

 

[Joe Fallon]

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.

 

[Cor]

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

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