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 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
"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: 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...
|
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...
|
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...
|
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 =...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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)...
| |