Passing multiple objects using a Session Variable Array

[Elton Kostecka]

I am working on several pages that are part of a registration process. On one
page, I am allowing the user to enter multiple registrations before moving on
to the next page. I want to capture all the registration object(s) into one
session variable. On subsequent screens, I want to be able to access the data.

How would you set up a session variable to hold all these registration
objects? There could be from 1 to 10 registrations (and all their ancillary
data) to capture. I am trying to use a temporary array to capture the data,
then save it all to a session variable (array?) before moving on.

Or, is there a better way?

Thanks.

 

[Cor Ligthert[MVP]]

Elton,

Maybe the viewstate?

http://msdn.microsoft.com/en-us/library/4yfdwycw.aspx

Cor

 

[Michel Posseth [MCP]]

Elton ,

If you would use the viewstate for this it would mean that all data has to
be pushed from the client to the server on every call
while with session variabels you would potentially drain the servers
resources.

Another solution could be to use a database , i have once created a system
that created a GUID with the start of the session for ordering purposes
the user could select all sorts of parts and at the end transfer them to a
order basket and order them , in the sql server i run run a maintenance
script that every 60 minutes checks if there are incomplete ( abandoned )
orders and so remove them ( one every page click i updated a heartbeat date
time field )

This system is in use for 60.000 users throughout europe and runs until the
day of today on a Poweredge 2400 running on windows 2003 web edition ( 2
GB mem ) but with a Poweredge 6400 MSSQL 2000 server with 8 GB and 1 TB
Harddisk space in raid 10 ( fast IO ) and dedicated GB network to the
webserver.
For really large amounts of data i would recomend you just use a pointer for
fields in a database , and create a system to remove orphaned data
for small amounts of data session variabels and viewstate are handy and easy
to use .

In the past i used Coockies however now i would probably have choosen the
viewstate to hold the pointer

regards

Michel

 

[Mr. Arnold]

Elton ,

If you would use the viewstate for this it would mean that all data has to
be pushed from the client to the server on every call
while with session variabels you would potentially drain the servers
resources.

That's why MS with an ASP.Net solution running on IIS6 and above have the
ability to use an ASP.NET state sever to hold session state for a ASP.NET
solution, and memory on a Web server is not used to hold session state.

The ASP.NET state server can be another computer/server on the network, or
it can be a server that's running MS SQL server with SQL server being the
state server. The state server can hold session state information for an
individual Web server or for all the Web servers in a Web server farm.

 

[Michel Posseth [MCP]]

That's why MS with an ASP.Net solution running on IIS6 and above have the
ability to use an ASP.NET state sever to hold session state for a ASP.NET
solution, and memory on a Web server is not used to hold session state.

The ASP.NET state server can be another computer/server on the network,
or it can be a server that's running MS SQL server with SQL server being
the state server. The state server can hold session state information for
an individual Web server or for all the Web servers in a Web server farm.

Yes that would also be an option , for the OP i didn`t mention it cause i
have bad experiences with it`s usage
personally i prefer a custom solution cause it is much more lightweight (
you only need to implement it where neded) you can then inmediatly use the
data in your BL, with a state server you do not end up with usable data in
your database but must perform extra roundtrips .

As long as you do not have a load balanced server farm and a rich IT budget
i would say Keep It Bloody Simple

ofcourse above is just my opinion , maybe someone else has good experiences
with it but i was once forced to use it ( server farm with load balancing )
and it needed a lot of extra coding wich in my opinion could be much
simpeler .

Another option could be to create a BL structure for the required
information and serialize the data to disk this is fast , easy to implement
and only requires a location weher your process has read / write access to
write the XML or Binary data , if the session ends you just delete the file


Michel

 

[Mr. Arnold]

Yes that would also be an option , for the OP i didn`t mention it cause i
have bad experiences with it`s usage
personally i prefer a custom solution cause it is much more lightweight
( you only need to implement it where neded) you can then inmediatly use
the data in your BL, with a state server you do not end up with usable
data in your database but must perform extra roundtrips .

The purpose of a state sever is to keep session state for any ASP.NET Web
solution, which can be done at the BLL as well. It's not a good solution
IMHO if the ASP.NET Web developer must keep session state by their own
devices - not good at all.

As long as you do not have a load balanced server farm and a rich IT
budget i would say Keep It Bloody Simple

I disagree here becuase what you purpose is not a simple solution of just
using an ASP.NET state server, if a Web server or Web servers do not have
the resouces to hold session state in memory for the many clients that a Web
server would service.

ofcourse above is just my opinion , maybe someone else has good
experiences with it but i was once forced to use it ( server farm with
load balancing ) and it needed a lot of extra coding wich in my opinion
could be much simpeler .

No, an ASP.NET solution using a state server is pretty much transparent to
the ASP.NET Web developer, if the infrastructure is set-up properly.

Another option could be to create a BL structure for the required
information and serialize the data to disk this is fast , easy to
implement and only requires a location weher your process has read /
write access to write the XML or Binary data , if the session ends you
just delete the file

Of course, you know that none of that would fly in a ASP.NET N-tiered
enterprise solution for a single Web server solution or a Web server farm. I
simply would have nothing to do with what you have proposed above in no way,
shape, form or fashion would I do such a thing in keeping state. But that's
just me and my opinion on what you have stated.

I have had nothing but good experiences using ASP.NET solutions that keep
state using an ASP.NET state server as part of the infrastructure. If things
are set-up properly, session state takes care of itself without the ASP.NET
Web developer worrying or being concerned about how state is keep for a give
ASP.NET solution that needs to keep state, when using an ASP.NET state
server as part of the WEB server infrastructure.

And keeping objects in a viewstate, what can be said about it? ;-)