Getting Away From Session-Level Variables

[David Krussow]

Before refactoring my code, just wanted to get your opinion. My objective is
to allow users to open a page, make some changes, and then possibly hours
later post back to the server so their changes can get saved to a SQL Server
database. Sessions necessarily time out, and are therefore not a good option
for storing data required on postback. Please check my reasoning on getting
away from storing things in the Session.

In the current version (the one I'm getting away from), when the user
requests an ASPX page a few variables (int and string values) and relatively
small DataSet are stored in the Session. On postback the code reads or
updates the variables and/or DataSet, then updates a SQL Server database.
One of my concerns about this arrangement is that the Session may time-out -
thereby destroying the variables and DataSet, in which case the postback
logic would fail.

I'm thinking that it might be better to never store the variables and
DataSet in the Session and instead (1) store the variable values in the
ViewState and (2) rebuild the DataSet whenever it's needed by the PostBack
logic. While this would create more round-trip data (larger viewState) and
incur an additional hit on the database, I'd at least meet my objective of
enabling the user's changes to get saved on postback - even in cases where
the postback occurs a long time after the Session has timed-out.

Thoughts, opionions, suggestions, alternatives?

Thanks in advance!

 

[John Saunders]

Before refactoring my code, just wanted to get your opinion. My objective is
to allow users to open a page, make some changes, and then possibly hours
later post back to the server so their changes can get saved to a SQL Server
database.

Are your users OK with losing their changes if after hours of changes, just
before they post back, they lose their browser session or their machine
crashes?

 

[bruce barker]

don't use viewstate. its a big performance bottleneck, and some proxy
servers will limit the size. use sqlserver sessions, or save the dataset in
a session column (store the key in the viewstate).

-- bruce (sqlwork.com)

 

[David Krussow]

<<<<Are your users OK with losing their changes if after hours of changes,
just before they post back, they lose their browser session or their
machine crashes.>>>>

Yes - they are okay with that and so am I. I'm primarily interested in
saving the users the inconvenience of having to re-enter data into the UI
that can't be saved simply because some key values that had been stored in
the Session were lost when the session expired.

I like Bruce's recommendation of storing Session state in SQL Server,
however, this solution will be on a hosted server - so I'm looking to reduce
complexity and dependencies as much as possible. I don't want to have to ask
too much of the hosting provider. I know they'll do it, but I don't want to
deal with them on this.

Thanks.

 

[Kevin Spencer]

Sounds quite reasonable, assuming that you expect a good number of users to
wait until their Session times out for one reason or another. There are
other ways of handling this, but your method would certainly work, and
accomplish your design goal.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Guest]

Or, persist the user data yourself--e.g. DataSet.WriteXML or some such. You need to come up with your own scheme for how to "find" it again (e.g. by user id), bit imho sometimes it's nice to keep this sort of data out of the database, in particular if you ever want your users to be able to work on that data in a disconnected mode. Keeping separate files might be too much overhead if you have thousands of anonymous users, but it doesn't sound like that's your case. I concur with the other posters that having data you care at all about just sitting there all day with no persistence is scary