Session State without HttpSessionState

[Mike]

I have the need to keep a substantial amount of session state, but I
do not have the option of using the HttpSessionState object. My
current scheme for dealing with this is to convert all the state
values to strings, place them in the query string of the URL passed to
Server.transfer(), and then pull them out again in the next page.
This has a number of problems including the following:

- I have to manually marshall the state to and from a string
representation.
- The query string is limited in length.

The ViewState mechanism almost provides a solution for me. It handles
the marshalling and doesn't have a hard size limit. However, it is
apparent that the designers of the ViewState mechanism did not allow
for the possibility of transfering the contents of view state from one
page to another. I've run into all sorts of problems trying to find
some sort of way to do this. The following things get in the way:

- You can't easily inherit all pages from a common base class.
- View State is unreliable in the Init event.
- The Load event of the Page object fires before the Load event of its
children.

Has anyone found a decent solution to my problem and would they care
to share it?


FYI: HttpSessionState is not an option because the application is
distributed across multiple load blanced web servers that are
controled by a beauacracy that decided the environment doesn't need a
state server. Additionally, unless I don't understand something, a
state server seems to put an artificial limit on the redundancy of the
environment, because it represents a single point of failure.

 

[Marina]

You are correct about single pt of failure. However, what about keeping
session info in SQL server? That is easily implemented, and should solve
your problems.

Another option is to generate your own session id, and pass it around via
query string or viewstate, or whatever.

Create your own object with properties for things you need to store for each
session that you created this way. Then place this object into the
Application object, indexing by the sessionid you generated. This works,
you are basically running your own session state here, your only
responsibility is to pass the session id you created around from page to
page.

However, if you have multiple server involved, this means each subsequent
request by the user needs to be to the same machine that initially processed
the request.

 

[Scott Allen]

Are you using SQL Server (or any backend DB) and if so - is keeping
state in the database an option?

 

[Mike]

You are correct about single pt of failure. However, what about keeping
session info in SQL server? That is easily implemented, and should solve
your problems.

Thank you for your response.

While storing the state in the database will solve the size limitation
option, it still requires me to come up with a marshalling mechanism.
This would involve more complexity than I am willing to accept.

Another option is to generate your own session id, and pass it around via
query string or viewstate, or whatever.

If this was a possibility for me, which it isn't, it would be the ugly
step-child of using the HttpSessionState, no?

I'm trying to avoid reinventing the wheel.

 

[Random]

I think the SQL Server option that has been discussed is your best bet. But
to address something you said in your post ("you can't easily inherit all
pages from a common base class"); actually, yes you can. Construct your
base class to Inherit from System.Web.UI.Page, and then modify your Page
declaration to read <@ Page Inherits="MyCommonBaseClass" > (with the other
attributes as well, of course). Yes, this will work with Master Pages, too,
but you have to inherit from System.Web.UI.MasterPage, and accessing page
elements is a little trickier.

 

[Scott Allen]

Hi Mike:

The mechanism for marshaling (serialization and rehydration) already
exists with the SerializableAttribute. Be more concerned about
performance testing to make sure it is a fit for your application.