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 10 2137
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
"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.
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.
"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
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
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
"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.
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
> 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
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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....
|
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...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |