By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,136 Members | 1,089 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,136 IT Pros & Developers. It's quick & easy.

Session level Object

P: n/a
I've got an ASP.NET application and I need some information on every page
like the user's name as well as a collection listing which sections of the
application the user has access to. I could store the user name in a regular
session variable but the collection varies in size based on the user and
could grow in the future as the application grows. I don't want to keep
going back to the database for this info every time because it's needed on
every page.What I would like to do is have a session level "USER" object
that stores this information in memory but I have not been able to figure
out how to do this. I have been looking on the web and I found this syntax:

<object id="UserInfo" runat="server" class="TestApplication.UserInfoClass"
scope="Session" />

This looks like exactly what I am looking for except I don't know how to add
this to my global.asax file. It does not belong in the codebehind
global.asax.vb file and there is no html view of the global.asax file. I'm
stumped.

Any help would be greatly appreciated.

Paul Ross
Hebco, Inc.
Nov 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Paul,

Storing a "User" object in session state does not save anything over just
using a normal session variable. They are both held in memory on the
server. The object approach stores the data in a nice package, but it isn't
more (or less efficient) than just storing session variables.

Other things to be careful about when using sessions is that if using a web
farm (load balanced servers), the session ID will not transfer between
servers.

The most common approach is to use a database. This is the most scalable
and robust solution. Yes, you will need to make trips to the db server, but
you are not holding anything in web server memory.
"Pross" <ta******@aol.com> wrote in message
news:ed**************@TK2MSFTNGP10.phx.gbl...
I've got an ASP.NET application and I need some information on every page
like the user's name as well as a collection listing which sections of the
application the user has access to. I could store the user name in a
regular session variable but the collection varies in size based on the
user and could grow in the future as the application grows. I don't want
to keep going back to the database for this info every time because it's
needed on every page.What I would like to do is have a session level
"USER" object that stores this information in memory but I have not been
able to figure out how to do this. I have been looking on the web and I
found this syntax:

<object id="UserInfo" runat="server" class="TestApplication.UserInfoClass"
scope="Session" />

This looks like exactly what I am looking for except I don't know how to
add this to my global.asax file. It does not belong in the codebehind
global.asax.vb file and there is no html view of the global.asax file. I'm
stumped.

Any help would be greatly appreciated.

Paul Ross
Hebco, Inc.

Nov 18 '05 #2

P: n/a
I'm not looking for efficiency over session variables. Using a simple object
would make it easier and to navigate some of the hierarchical data. For
instance my "Job" object contains a collection of "Task" objects that
describe each separate task that makes up a job. Some Jobs have 1 task and
some others have 20. The session variable (at least as I have used them) are
great for single pieces of data but don't seem to be able to hold
hierarchical data in a way that would be easy to deal with.

I have been able to create global object in the application by a couple of
different methods but only one object gets created and all the clients are
modifying that one object. What I would like to do is to have a copy of this
object for each client logged in. I know this has some potential side
effects not the least of which is memory but this is an internal web app and
I don't anticipate a lot of simultaneous users. I plan to do a lot of
testing of whatever solution I come up with but I would like to be able to
evaluate this idea as a solution. I was hoping to get some help in making it
work.

Paul Ross
Hebco, Inc.

"Scott M." <s-***@nospam.nospam> wrote in message
news:uj**************@TK2MSFTNGP10.phx.gbl...
Paul,

Storing a "User" object in session state does not save anything over just
using a normal session variable. They are both held in memory on the
server. The object approach stores the data in a nice package, but it
isn't more (or less efficient) than just storing session variables.

Other things to be careful about when using sessions is that if using a
web farm (load balanced servers), the session ID will not transfer between
servers.

The most common approach is to use a database. This is the most scalable
and robust solution. Yes, you will need to make trips to the db server,
but you are not holding anything in web server memory.
"Pross" <ta******@aol.com> wrote in message
news:ed**************@TK2MSFTNGP10.phx.gbl...
I've got an ASP.NET application and I need some information on every page
like the user's name as well as a collection listing which sections of
the application the user has access to. I could store the user name in a
regular session variable but the collection varies in size based on the
user and could grow in the future as the application grows. I don't want
to keep going back to the database for this info every time because it's
needed on every page.What I would like to do is have a session level
"USER" object that stores this information in memory but I have not been
able to figure out how to do this. I have been looking on the web and I
found this syntax:

<object id="UserInfo" runat="server"
class="TestApplication.UserInfoClass" scope="Session" />

This looks like exactly what I am looking for except I don't know how to
add this to my global.asax file. It does not belong in the codebehind
global.asax.vb file and there is no html view of the global.asax file.
I'm stumped.

Any help would be greatly appreciated.

Paul Ross
Hebco, Inc.


Nov 18 '05 #3

P: n/a
Paul,

Are you aware that objects can be persisted in the ASP.NET state bag (view
state)? This allows you to make an instance of your object, populate it and
then place it in the ViewState state bag for retrieval on another page
request.
"Pross" <ta******@aol.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
I'm not looking for efficiency over session variables. Using a simple
object would make it easier and to navigate some of the hierarchical data.
For instance my "Job" object contains a collection of "Task" objects that
describe each separate task that makes up a job. Some Jobs have 1 task and
some others have 20. The session variable (at least as I have used them)
are great for single pieces of data but don't seem to be able to hold
hierarchical data in a way that would be easy to deal with.

I have been able to create global object in the application by a couple of
different methods but only one object gets created and all the clients are
modifying that one object. What I would like to do is to have a copy of
this object for each client logged in. I know this has some potential side
effects not the least of which is memory but this is an internal web app
and I don't anticipate a lot of simultaneous users. I plan to do a lot of
testing of whatever solution I come up with but I would like to be able to
evaluate this idea as a solution. I was hoping to get some help in making
it work.

Paul Ross
Hebco, Inc.

"Scott M." <s-***@nospam.nospam> wrote in message
news:uj**************@TK2MSFTNGP10.phx.gbl...
Paul,

Storing a "User" object in session state does not save anything over just
using a normal session variable. They are both held in memory on the
server. The object approach stores the data in a nice package, but it
isn't more (or less efficient) than just storing session variables.

Other things to be careful about when using sessions is that if using a
web farm (load balanced servers), the session ID will not transfer
between servers.

The most common approach is to use a database. This is the most scalable
and robust solution. Yes, you will need to make trips to the db server,
but you are not holding anything in web server memory.
"Pross" <ta******@aol.com> wrote in message
news:ed**************@TK2MSFTNGP10.phx.gbl...
I've got an ASP.NET application and I need some information on every
page like the user's name as well as a collection listing which sections
of the application the user has access to. I could store the user name
in a regular session variable but the collection varies in size based on
the user and could grow in the future as the application grows. I don't
want to keep going back to the database for this info every time because
it's needed on every page.What I would like to do is have a session
level "USER" object that stores this information in memory but I have
not been able to figure out how to do this. I have been looking on the
web and I found this syntax:

<object id="UserInfo" runat="server"
class="TestApplication.UserInfoClass" scope="Session" />

This looks like exactly what I am looking for except I don't know how to
add this to my global.asax file. It does not belong in the codebehind
global.asax.vb file and there is no html view of the global.asax file.
I'm stumped.

Any help would be greatly appreciated.

Paul Ross
Hebco, Inc.



Nov 18 '05 #4

P: n/a
If this process creates a separate instace for each user that that's exactly
what I want. Do you know a good site to read up on this?

Thanks,

Paul Ross
Hebco, Inc.
Nov 18 '05 #5

P: n/a
Scott,

I was reading another post and I discovered something that I'm sure you knew
all along but I did not know. I came from old ASP where session variables
were only strings and I thought that was still the case. I read a post where
someone was just assigning their objuct directly to a session variable. I
did not know that you could do that. I'm sorry for wasting your time. I
tried this and it works exactly like I'd hoped. If only everysolution in
life were this easy. Well back to the grind.

Paul Ross
Hebco, Inc.
Nov 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.