Some basic session state questions

[codegreen9]

Hi,

My understanding is that session info must be stored using
Session["var"], which means text data. What I'd like to be able to do,
is keep an object alive throughout a user's session, without having to
serialize my data into text, save it as Session["var"], and restore it
using Session["var"] every time the user moves to a different page.

Is there no way to have a session *object* stay in memory and preserve
variable state without serialize/deserialize/Session[] ?

Also, depending on what a user is doing, I'd like to temporarily store
his/her selections in SQL, for the duration of the session, then wipe
out that temporary data when the session expires. Is there a way I can
use the .net framework to do that? By notifying me or a SQL stored
procedure to clean out that data? I could use a scheduled stored proc
to wipe out old temp data, I just wondered if there's anything in
ASP.NET that I could tap into.

Thanks in advance

[Hans Kesting]

> Hi,

My understanding is that session info must be stored using
Session["var"], which means text data. What I'd like to be able to do,
is keep an object alive throughout a user's session, without having to
serialize my data into text, save it as Session["var"], and restore it
using Session["var"] every time the user moves to a different page.

Is there no way to have a session *object* stay in memory and preserve
variable state without serialize/deserialize/Session[] ?
Thanks in advance

In Session you store *objects* (or rather: *references* to objects),
not just strings. So you can store any object there without
(de)serialization. That is, if you use "InProc" sessions. When you use
StateServer or SqlServer to store session data, then the object needs
to be serializable, but you don't have to do it yourself.
When you retrieve the object from Session, you have to cast is to the
correct type.

MyObject obj = new MyObject();
Session["mine"] = obj;
....
MyObject obj2 = (MyObject)Session["mine"];
By the way, there is also a microsoft.public.dotnet.framework.aspnet
newsgroup...
Hans Kesting

[Michael Nemtsev]

Do u really need SQL for this? Why not to use just Cache, or StateServer?
SQL/StateServer are aimed to keep you data permanently.

BTW, if you want to clear your tables in case of session end call you SQL
script in the Session_End handler in global.aspx

Also, depending on what a user is doing, I'd like to temporarily store
his/her selections in SQL, for the duration of the session, then wipe
out that temporary data when the session expires. Is there a way I can
use the .net framework to do that? By notifying me or a SQL stored
procedure to clean out that data? I could use a scheduled stored proc
to wipe out old temp data, I just wondered if there's anything in
ASP.NET that I could tap into.

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[codegreen9]

Thanks very much for the replies.

Hans: Thanks for the info. Also, the .aspnet group would have been
more appropriate, thanks for mentioning it. Is it a common (or
advisable) practice to save and restore the Page object itself
(InProc)?

Michael: Thanks for pointing out Session_End. For this project, I have
a reason to use SQL other than simply as a mechanism for storing
session info. The reason for storing info in SQL would be to set up
another stored procedure call that I'll need to do. This boils down to
a "best practices" SQL question. The user will be able to select 1-600
items, which translate into rows in table A. So, I think the "best
practice" option would be to bulk insert the selections into another
SQL table (table B), and use a join to pull out the data from table A,
which could be done with a single stored procedure call. Then I'd need
to clean out table B.

Other options would be making a stored procedure call for every
selection (up to 600, not very efficient), or passing the selections as
an array and parsing (not very relational).

After writing this post, I think I'll end up pulling all rows from
table A once, at the application level (the data is pretty static), and
use DataViews at the session level to let users pick and choose their
data. One SQL stored proc call per day... yeah, i like that better...
:)