473,287 Members | 1,741 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

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

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
May 16 '06 #1
10 2135
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!
*************************************************
"Mark Rae" <ma**@markN-O-S-P-A-M.co.uk> wrote in message
news:eG**************@TK2MSFTNGP05.phx.gbl...
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

May 16 '06 #2
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamM> wrote in
message news:er**************@TK2MSFTNGP02.phx.gbl...
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.
May 16 '06 #3
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


"Mark Rae" wrote:
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamM> wrote in
message news:er**************@TK2MSFTNGP02.phx.gbl...
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.

May 16 '06 #4
"Peter Bromberg [C# MVP]" <pb*******@yahoo.nospammin.com> wrote in message
news:F1**********************************@microsof t.com...

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
May 16 '06 #5

Mark,

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

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


"Mark Rae" <ma**@markN-O-S-P-A-M.co.uk> wrote in message
news:OM**************@TK2MSFTNGP05.phx.gbl...
"Peter Bromberg [C# MVP]" <pb*******@yahoo.nospammin.com> wrote in message
news:F1**********************************@microsof t.com...

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

May 16 '06 #6
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" <ma**@markN-O-S-P-A-M.co.uk> wrote in message
news:eG**************@TK2MSFTNGP05.phx.gbl...
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

May 16 '06 #7
"bruce barker (sqlwork.com)" <b_*************************@sqlwork.com> wrote
in message news:uN**************@TK2MSFTNGP05.phx.gbl...
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.
May 16 '06 #8
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? :P

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

bruce barker (sqlwork.com) wrote:
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" <ma**@markN-O-S-P-A-M.co.uk> wrote in message
news:eG**************@TK2MSFTNGP05.phx.gbl...
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


May 16 '06 #9
> If an object has methods and is serialized does it just
lose it's methods when it is deserialized?
No.
Ray Booysen wrote: 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? :P

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

bruce barker (sqlwork.com) wrote:
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" <ma**@markN-O-S-P-A-M.co.uk> wrote in message
news:eG**************@TK2MSFTNGP05.phx.gbl...
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



May 17 '06 #10
Russell wrote:
If an object has methods and is serialized does it just
lose it's methods when it is deserialized?
No.


Really good explanation. ;)


Ray Booysen wrote:
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? :P

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

bruce barker (sqlwork.com) wrote:
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" <ma**@markN-O-S-P-A-M.co.uk> wrote in message
news:eG**************@TK2MSFTNGP05.phx.gbl...
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

May 17 '06 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: mjkahn | last post by:
I've read (and read!) that you shouldn't store objects in Session variables. I've read these reasons: - The object takes up memory that may not be freed until the session times out. Better to...
2
by: Anthony Reynolds | last post by:
I am trying to persist an instance of my class between asp pages and cannot get it to work consistently. I have one class that implements iEnumerator, that works fine. I have another class that...
3
by: MrShovel | last post by:
I'm new to this ASP.NET caper and have the following questions. I have a TestObject that contains about 50 fields of data and 3 member procedures. Below is a simplified explanation of what I do....
9
by: david | last post by:
I have a class with some business-logic and with every roundtrip, I need an instance of this class, so I have to create it, every time again. That doesn't seem very efficient. I thought it would...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.