Storing objects (classes) in Session in ASP.NET 2

[Mark Rae]

Hi,

This relates to the previous thread "Disappearing Sessions", but is a bit
more generic so I thought I'd start a new thread. This one relates to the
storing of objects in Session once only to prevent the system having to
constantly query the database for the same information.

I'm currently upgrading a v1.1 app to v2 (that's all I seem to do these
days!), and it contains a class called CUser which holds details of the
currently logged-on user e.g. firstname, surname, email address,
administrator or not, user type etc. The CUser class has a Fetch() method
which populates its properties. When the site is first accessed, the user is
presented with a login page where they type their username and password;
this data is evaluated against the database and, if valid, a new CUser
object is instantiated, the Fetch() method called and the object stored in
Session.

This Session object is used pretty much all through the rest of the app.
E.g., there is a menu.ascx control which builds up a dynamic menu structure
depending on various properties of the CUser object etc.

In v1.1, the following code was used as and when needed:

CUser objUser = null;

try
{
objUser = (CUser)HttpContext.Current.Session["objUser"];
if (objUser.blnAdministrator)
{
// display the administrator menu
}
else
{
// display the standard menu
/*
}
catch (Exception ex)
{
throw(ex);
}
finally
{
objUser = null;
}

However, in v2, the last line (objUser = null) sets the Session["objUser"]
object to null which, of course, stops the app dead in its tracks - this
didn't (appear to) happen in v1.1.

Is this because in v1.1 the above code made a copy of the Session object,
but in v2 it is referencing the Session object directly?

What I'm looking to achieve here is to fetch the currently logged-on user's
details once only (in Session_Start), store them in Session, and then refer
to them as required rather than to keep fetching them from SQL Server.

Would appreciate some thoughts as to the most efficient way to do this.

Mark

 

[Cowboy \(Gregory A. Beamer\)]

You have an assumption that a failure to fill should cause a reset to null?
Why? Is this because you have code like this elsewhere:

if(objUser == null)

I would not rely on the nullability of an object. Instead, create the object
and then have the fill method set the key property (generally tied to the
key column in the DB). If the key is set to 0 (default), you know the user
is not authenticated. Much better than taking a chance.

An even better model would be to pull the user rights and if the user has
none, set an authenticated property to false. Then you can boot them. Having
the full rights set up allows you to poll on more than just admin/user. You
may not have the concept of roles in your database, so this may be a moot
point.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************

Hi,

This relates to the previous thread "Disappearing Sessions", but is a bit
more generic so I thought I'd start a new thread. This one relates to the
storing of objects in Session once only to prevent the system having to
constantly query the database for the same information.

I'm currently upgrading a v1.1 app to v2 (that's all I seem to do these
days!), and it contains a class called CUser which holds details of the
currently logged-on user e.g. firstname, surname, email address,
administrator or not, user type etc. The CUser class has a Fetch() method
which populates its properties. When the site is first accessed, the user
is presented with a login page where they type their username and
password; this data is evaluated against the database and, if valid, a new
CUser object is instantiated, the Fetch() method called and the object
stored in Session.

This Session object is used pretty much all through the rest of the app.
E.g., there is a menu.ascx control which builds up a dynamic menu
structure depending on various properties of the CUser object etc.

In v1.1, the following code was used as and when needed:

CUser objUser = null;

try
{
objUser = (CUser)HttpContext.Current.Session["objUser"];
if (objUser.blnAdministrator)
{
// display the administrator menu
}
else
{
// display the standard menu
/*
}
catch (Exception ex)
{
throw(ex);
}
finally
{
objUser = null;
}

However, in v2, the last line (objUser = null) sets the Session["objUser"]
object to null which, of course, stops the app dead in its tracks - this
didn't (appear to) happen in v1.1.

Is this because in v1.1 the above code made a copy of the Session object,
but in v2 it is referencing the Session object directly?

What I'm looking to achieve here is to fetch the currently logged-on
user's details once only (in Session_Start), store them in Session, and
then refer to them as required rather than to keep fetching them from SQL
Server.

Would appreciate some thoughts as to the most efficient way to do this.

Mark

 

[Mark Rae]

You have an assumption that a failure to fill should cause a reset to
null? Why? Is this because you have code like this elsewhere:

if(objUser == null)

Thanks for the reply, but I think you've misunderstood my question.

CUser objUser = (CUser)HttpContext.Current.Session["objUser"];

In v1.1 the above line of code "appeared" to create a copy of the
Session["objUser"] object - therefore, setting the objUser variable to null
simply destroyed the copy of the Session["objUser"] object being used at
that time, i.e. the code cleaned up after itself.

In v2, the above line of code "appears" to be referencing the
Session["objUser"] object directly - therefore setting the objUser variable
to null removes the object from Session.

 

[Guest]

Mark,
Personally I believe it is better to stay away from Session entirely for
"User" type objects. You could create a CustomPrincipal class derived from
IPrincipal, populate this in Application_AuthenticateRequest in global.asax,
and attach this to the currentContexxt.User object. In this manner it would
travel with the page throughout the user's site visit with no dependency at
all on Session. Plus, if you have implemented it, you can use the built - in
User.IsInRole method.

Just my 2 cents.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

You have an assumption that a failure to fill should cause a reset to
null? Why? Is this because you have code like this elsewhere:

if(objUser == null)

Thanks for the reply, but I think you've misunderstood my question.

CUser objUser = (CUser)HttpContext.Current.Session["objUser"];

In v1.1 the above line of code "appeared" to create a copy of the
Session["objUser"] object - therefore, setting the objUser variable to null
simply destroyed the copy of the Session["objUser"] object being used at
that time, i.e. the code cleaned up after itself.

In v2, the above line of code "appears" to be referencing the
Session["objUser"] object directly - therefore setting the objUser variable
to null removes the object from Session.

 

[Mark Rae]

Peter,

Personally I believe it is better to stay away from Session entirely for
"User" type objects.

<snip>

That's great, but do you happen to know if referencing objects stored in
Session has changed between v1.1 and v2 - that's what I'm actually trying to
find out...

Mark

 

[sloan]

Mark,

I've been running my "Web Session Object Wrapper" in 2.0 without issues.

http://spaces.msn.com/sholliday/ 10/24/2005 entry.

 

[bruce barker \(sqlwork.com\)]

your diagnoses is wrong. after:

objUser = (CUser)HttpContext.Current.Session["objUser"];

objUser is a reference to the object in session, not a copy (in v1 & v2).
this means if you change a property or call a methods it the same as
referencing (CUser)HttpContext.Current.Session["objUser"], which in itself
is just a reference to the real object. the line

objUser = null;

just makes objUser null, it has no effect on the session variable. you will
have to look elsewhere for your problem.

-- bruce (sqlwork.com)

 

[Mark Rae]

just makes objUser null, it has no effect on the session variable. you
will have to look elsewhere for your problem.

That's what I wanted to know - thanks very much.

 

[Ray Booysen]

Unless I'm mistaken, unless you're running session inproc, your method
won't be allowed in session because its not serializable. Urgh, I can't
remember. If an object has methods and is serialized does it just
lose it's methods when it is deserialized?

Anyway, my point is to be careful whwat you place in session because if
it comes time to move to session in SQL or state server, your objects
are required to be serializable.

Regards
Ray

your diagnoses is wrong. after:

objUser = (CUser)HttpContext.Current.Session["objUser"];

objUser is a reference to the object in session, not a copy (in v1 & v2).
this means if you change a property or call a methods it the same as
referencing (CUser)HttpContext.Current.Session["objUser"], which in itself
is just a reference to the real object. the line

objUser = null;

just makes objUser null, it has no effect on the session variable. you will
have to look elsewhere for your problem.

-- bruce (sqlwork.com)

Hi,

This relates to the previous thread "Disappearing Sessions", but is a bit
more generic so I thought I'd start a new thread. This one relates to the
storing of objects in Session once only to prevent the system having to
constantly query the database for the same information.

I'm currently upgrading a v1.1 app to v2 (that's all I seem to do these
days!), and it contains a class called CUser which holds details of the
currently logged-on user e.g. firstname, surname, email address,
administrator or not, user type etc. The CUser class has a Fetch() method
which populates its properties. When the site is first accessed, the user
is presented with a login page where they type their username and
password; this data is evaluated against the database and, if valid, a new
CUser object is instantiated, the Fetch() method called and the object
stored in Session.

This Session object is used pretty much all through the rest of the app.
E.g., there is a menu.ascx control which builds up a dynamic menu
structure depending on various properties of the CUser object etc.

In v1.1, the following code was used as and when needed:

CUser objUser = null;

try
{
objUser = (CUser)HttpContext.Current.Session["objUser"];
if (objUser.blnAdministrator)
{
// display the administrator menu
}
else
{
// display the standard menu
/*
}
catch (Exception ex)
{
throw(ex);
}
finally
{
objUser = null;
}

However, in v2, the last line (objUser = null) sets the Session["objUser"]
object to null which, of course, stops the app dead in its tracks - this
didn't (appear to) happen in v1.1.

Is this because in v1.1 the above code made a copy of the Session object,
but in v2 it is referencing the Session object directly?

What I'm looking to achieve here is to fetch the currently logged-on
user's details once only (in Session_Start), store them in Session, and
then refer to them as required rather than to keep fetching them from SQL
Server.

Would appreciate some thoughts as to the most efficient way to do this.

Mark

 

[Russell]

If an object has methods and is serialized does it just

lose it's methods when it is deserialized?

No.

Unless I'm mistaken, unless you're running session inproc, your method
won't be allowed in session because its not serializable. Urgh, I can't
remember. If an object has methods and is serialized does it just
lose it's methods when it is deserialized?

Anyway, my point is to be careful whwat you place in session because if
it comes time to move to session in SQL or state server, your objects
are required to be serializable.

Regards
Ray

your diagnoses is wrong. after:

objUser = (CUser)HttpContext.Current.Session["objUser"];

objUser is a reference to the object in session, not a copy (in v1 & v2).
this means if you change a property or call a methods it the same as
referencing (CUser)HttpContext.Current.Session["objUser"], which in itself
is just a reference to the real object. the line

objUser = null;

just makes objUser null, it has no effect on the session variable. you will
have to look elsewhere for your problem.

-- bruce (sqlwork.com)

Hi,

This relates to the previous thread "Disappearing Sessions", but is a bit
more generic so I thought I'd start a new thread. This one relates to the
storing of objects in Session once only to prevent the system having to
constantly query the database for the same information.

I'm currently upgrading a v1.1 app to v2 (that's all I seem to do these
days!), and it contains a class called CUser which holds details of the
currently logged-on user e.g. firstname, surname, email address,
administrator or not, user type etc. The CUser class has a Fetch() method
which populates its properties. When the site is first accessed, the user
is presented with a login page where they type their username and
password; this data is evaluated against the database and, if valid, a new
CUser object is instantiated, the Fetch() method called and the object
stored in Session.

This Session object is used pretty much all through the rest of the app.
E.g., there is a menu.ascx control which builds up a dynamic menu
structure depending on various properties of the CUser object etc.

In v1.1, the following code was used as and when needed:

CUser objUser = null;

try
{
objUser = (CUser)HttpContext.Current.Session["objUser"];
if (objUser.blnAdministrator)
{
// display the administrator menu
}
else
{
// display the standard menu
/*
}
catch (Exception ex)
{
throw(ex);
}
finally
{
objUser = null;
}

However, in v2, the last line (objUser = null) sets the Session["objUser"]
object to null which, of course, stops the app dead in its tracks - this
didn't (appear to) happen in v1.1.

Is this because in v1.1 the above code made a copy of the Session object,
but in v2 it is referencing the Session object directly?

What I'm looking to achieve here is to fetch the currently logged-on
user's details once only (in Session_Start), store them in Session, and
then refer to them as required rather than to keep fetching them from SQL
Server.

Would appreciate some thoughts as to the most efficient way to do this.

Mark

 

[Ray Booysen]

No.

Really good explanation.

Unless I'm mistaken, unless you're running session inproc, your method
won't be allowed in session because its not serializable. Urgh, I can't
remember. If an object has methods and is serialized does it just
lose it's methods when it is deserialized?

Anyway, my point is to be careful whwat you place in session because if
it comes time to move to session in SQL or state server, your objects
are required to be serializable.

Regards
Ray

your diagnoses is wrong. after:

objUser = (CUser)HttpContext.Current.Session["objUser"];

objUser is a reference to the object in session, not a copy (in v1 & v2).
this means if you change a property or call a methods it the same as
referencing (CUser)HttpContext.Current.Session["objUser"], which in itself
is just a reference to the real object. the line

objUser = null;

just makes objUser null, it has no effect on the session variable. you will
have to look elsewhere for your problem.

-- bruce (sqlwork.com)




Hi,

This relates to the previous thread "Disappearing Sessions", but is a bit
more generic so I thought I'd start a new thread. This one relates to the
storing of objects in Session once only to prevent the system having to
constantly query the database for the same information.

I'm currently upgrading a v1.1 app to v2 (that's all I seem to do these
days!), and it contains a class called CUser which holds details of the
currently logged-on user e.g. firstname, surname, email address,
administrator or not, user type etc. The CUser class has a Fetch() method
which populates its properties. When the site is first accessed, the user
is presented with a login page where they type their username and
password; this data is evaluated against the database and, if valid, a new
CUser object is instantiated, the Fetch() method called and the object
stored in Session.

This Session object is used pretty much all through the rest of the app.
E.g., there is a menu.ascx control which builds up a dynamic menu
structure depending on various properties of the CUser object etc.

In v1.1, the following code was used as and when needed:

CUser objUser = null;

try
{
objUser = (CUser)HttpContext.Current.Session["objUser"];
if (objUser.blnAdministrator)
{
// display the administrator menu
}
else
{
// display the standard menu
/*
}
catch (Exception ex)
{
throw(ex);
}
finally
{
objUser = null;
}

However, in v2, the last line (objUser = null) sets the Session["objUser"]
object to null which, of course, stops the app dead in its tracks - this
didn't (appear to) happen in v1.1.

Is this because in v1.1 the above code made a copy of the Session object,
but in v2 it is referencing the Session object directly?

What I'm looking to achieve here is to fetch the currently logged-on
user's details once only (in Session_Start), store them in Session, and
then refer to them as required rather than to keep fetching them from SQL
Server.

Would appreciate some thoughts as to the most efficient way to do this.

Mark