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

Problem with asp.net app only allowing 1 user at a time

P: n/a
I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
i have made is running on IIS v6 and consists of a number of pages that allow
the user to read information from the database into classes, which are used
throughout the application. I have made class collections which, upon reading
from the DB, create an instance of the class and store the DB values in
there temporarily. My problem is that if user1 looks at record1, then user2
looks at record2, anything user1 does from that point onwards points the data
at record2.
Is there anything in particular i need to do to make the asp.net application
available to multiple users at the same time, each looking at different
records in the DB?
Thanks in advance
Nov 19 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
If I'm understanding you correctly you are loading data for the user
from the database then storing that data into application scope. The
issue that you then have is that you retrieve this data from application
scope the next time the page is displayed. If this is the case then you
should modify the way you are handling state management.

The Application object should only be used to store data that is truly
global to every user of the application. If you need to store things on
a per user basis you should look into using the Session object. Using
the Session object will allow you to store data classes on a per user
basis.

If you are worried about running the same query against the database
multiple times, then you might want to abstract the use of the
Application object (not a bad idea in general anyway) so that you can
store a collection of query result sets keyed by the query used, then
retrieve the appropriate result set for each user from the collection.
If the collection doesn't contain the appropriate result set then you
query the database and then add it to the collection and put the
collection back in Application scope. Once you retrieve the appropriate
result set from the application collection you could then put it in the
user's Session object and continue your retrieval from there.

Without more information on how you really intend to use these objects
it is hard to know which solution to use, but hopefully something from
the above will work for you.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
i have made is running on IIS v6 and consists of a number of pages that allow
the user to read information from the database into classes, which are used
throughout the application. I have made class collections which, upon reading
from the DB, create an instance of the class and store the DB values in
there temporarily. My problem is that if user1 looks at record1, then user2
looks at record2, anything user1 does from that point onwards points the data
at record2.
Is there anything in particular i need to do to make the asp.net application
available to multiple users at the same time, each looking at different
records in the DB?
Thanks in advance

Nov 19 '05 #2

P: n/a
I'm kinda new to professional asp.net development, so could you just clarify
the application and session objects?
I've got a module that houses many functions that all retrieve information
about their specific table from the database, writing the information into a
'.vb' class file. In effect, i am taking a snapshot of the database at that
current moment and storing it to the class, amending it there and then
writing changes back to the database afterwards. If i understand you
correctly, that is application level, therefore every user's instance of the
application sees the same data, whereas on a session level, each user would
see their own instance. Is this correct? If so, do you have any pointers
about making class files per session, not per application? I'm hugely
confused! The reason i'm developing like this is because i'm migrating an old
VB6 app and web-enabling it using ASP.NET. The old version used classes and i
was expected to re-use as much as possible. I think i understand that the
inherent difference is that with the old app it was installed seperately on
each computer, whereas the ASP.NET version is just one copy, installed on the
web server.
Any help would be gratefully receieved :)

"John M Deal" wrote:
If I'm understanding you correctly you are loading data for the user
from the database then storing that data into application scope. The
issue that you then have is that you retrieve this data from application
scope the next time the page is displayed. If this is the case then you
should modify the way you are handling state management.

The Application object should only be used to store data that is truly
global to every user of the application. If you need to store things on
a per user basis you should look into using the Session object. Using
the Session object will allow you to store data classes on a per user
basis.

If you are worried about running the same query against the database
multiple times, then you might want to abstract the use of the
Application object (not a bad idea in general anyway) so that you can
store a collection of query result sets keyed by the query used, then
retrieve the appropriate result set for each user from the collection.
If the collection doesn't contain the appropriate result set then you
query the database and then add it to the collection and put the
collection back in Application scope. Once you retrieve the appropriate
result set from the application collection you could then put it in the
user's Session object and continue your retrieval from there.

Without more information on how you really intend to use these objects
it is hard to know which solution to use, but hopefully something from
the above will work for you.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
i have made is running on IIS v6 and consists of a number of pages that allow
the user to read information from the database into classes, which are used
throughout the application. I have made class collections which, upon reading
from the DB, create an instance of the class and store the DB values in
there temporarily. My problem is that if user1 looks at record1, then user2
looks at record2, anything user1 does from that point onwards points the data
at record2.
Is there anything in particular i need to do to make the asp.net application
available to multiple users at the same time, each looking at different
records in the DB?
Thanks in advance

Nov 19 '05 #3

P: n/a
I really wish I had more time to get into this in depth, but I'm at work
right now so I'll have to keep this short and rely on your ability to
run with this info.

In ASP.Net (and classic ASP for that matter) there are a number of
intrinsic/built-in object provided globally by the environment itself.
Included in these objects is Response (the object that can send data
back to the client), Request (the object that contains the data sent
from the client to the server), Application (an object that can store
globally available data), and Session (an object that can store user
specific data). There are others but these will get you started. You
do not need to create these objects, you simply need to refer to them in
your code.

Now in your case you are reading and writing everything to the database,
so my original notes may not apply in your situation, you'll have to
decide that. However if you do decide to try and follow what I said
before you should know a couple of things.

First Application is created when the web application first starts up
and is available until the web application shuts down. You can catch
events that tell you when these happen in the Global.asax file(s).
You'll want to look into this because if you don't prepare your code for
it data may disappear during long periods of user inactivity and you may
want to reload it when the application reloads. The Application object
can be accessed by any of the connections/threads that are currently
active on the server. This means that you need to lock the access to the
Application object when modifying its contents so you don't run into
threading problems; to do this use Application.Lock() before you add
something to it and Application.Unlock() after you are done with it. Any
page that works with the Application object will be using data that is
available to all users connected to the system.

Second, there is the Session object. By default session only lasts
twenty minutes from the last time a user accessed the system (the server
does not have any other way to know if the user is still connected other
than if they make a request). This time limitation can be controlled in
the web.config file for the site. Session is only valid for a single
user connected to the system, however be aware that if the user opens
two separate browsers each one will have its own session (unless one was
launched from another then they share the same session). Session uses a
cookie by default to track an unique id that is used to retrieve data
for the specific user that it is associated to. When you store object
instances in Session they are only stored for (and retrievable by) the
browser instance associated to the unique id. Session can be made to
not require cookies (but then it puts the unique id in the querystring
for the page). Also Session can be configured to store its data in
memory (InProc) in an out of process Service (StateServer) or in an
external database (SqlServer). This is controlled by your web.config
file for the website (as is the session timeout). If you choose to
store session anywhere besides InProc (the default) you will have to
makes sure any object that you store in it is serializable or the system
will throw an exception (it uses serialization to marshal the object
across the process boundary between the site and the storage repository).

Now that all being said. Whether you use Application or Session you
store instances of objects (or primitives if you want) using a
name/value methodology. For example if you have an instance of an User
object called myUser and you want to put it in session you would do
something like (C# code):

Session["TheUserObjectKey"] = myUser;

To retrieve this you would do something like:

User myUser = (User) Session["TheUserObjectKey"];

This would work the same for the Application though you'd want to do the
Lock/Unlock pattern that I mentioned before. Also note that because
Application and Session store the base Object type you have to cast your
object back to the appropriate type when retrieving them back out.

Ok, that ran a bit longer than I thought it would but it is the basics
of how these objects work. Now if you want to store objects for the
users, you will want to see if their Session has an instance of your
data object, if it doesn't you'd query it from the database then put it
in Session, if it does you'll want to retrieve it from session and
display the appropriate values. Obviously you'll have to deal with the
issues involved with updating these data objects (if that is necessary
for your circumstances) and also you must realize that because
Application and Session have timeouts you will have objects hanging out
in memory until they expire (and then until the GC collects the object)
but this is standard for ASP.Net applications.

Hopefully this is enough to get you started. See the help files and
MSDN online documentation for more information. If you are looking to
do enterprise development in ASP.Net I'd really recommend that you
pickup a good ASP.Net book (search this newsgroup I'm sure you'll find
plenty of recommendations). Also there are some webcasts being done on
ASP.Net out on Microsoft's site that might give you some pointers. Hope
something here helps.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm kinda new to professional asp.net development, so could you just clarify
the application and session objects?
I've got a module that houses many functions that all retrieve information
about their specific table from the database, writing the information into a
'.vb' class file. In effect, i am taking a snapshot of the database at that
current moment and storing it to the class, amending it there and then
writing changes back to the database afterwards. If i understand you
correctly, that is application level, therefore every user's instance of the
application sees the same data, whereas on a session level, each user would
see their own instance. Is this correct? If so, do you have any pointers
about making class files per session, not per application? I'm hugely
confused! The reason i'm developing like this is because i'm migrating an old
VB6 app and web-enabling it using ASP.NET. The old version used classes and i
was expected to re-use as much as possible. I think i understand that the
inherent difference is that with the old app it was installed seperately on
each computer, whereas the ASP.NET version is just one copy, installed on the
web server.
Any help would be gratefully receieved :)

"John M Deal" wrote:

If I'm understanding you correctly you are loading data for the user
from the database then storing that data into application scope. The
issue that you then have is that you retrieve this data from application
scope the next time the page is displayed. If this is the case then you
should modify the way you are handling state management.

The Application object should only be used to store data that is truly
global to every user of the application. If you need to store things on
a per user basis you should look into using the Session object. Using
the Session object will allow you to store data classes on a per user
basis.

If you are worried about running the same query against the database
multiple times, then you might want to abstract the use of the
Application object (not a bad idea in general anyway) so that you can
store a collection of query result sets keyed by the query used, then
retrieve the appropriate result set for each user from the collection.
If the collection doesn't contain the appropriate result set then you
query the database and then add it to the collection and put the
collection back in Application scope. Once you retrieve the appropriate
result set from the application collection you could then put it in the
user's Session object and continue your retrieval from there.

Without more information on how you really intend to use these objects
it is hard to know which solution to use, but hopefully something from
the above will work for you.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
i have made is running on IIS v6 and consists of a number of pages that allow
the user to read information from the database into classes, which are used
throughout the application. I have made class collections which, upon reading
from the DB, create an instance of the class and store the DB values in
there temporarily. My problem is that if user1 looks at record1, then user2
looks at record2, anything user1 does from that point onwards points the data
at record2.
Is there anything in particular i need to do to make the asp.net application
available to multiple users at the same time, each looking at different
records in the DB?
Thanks in advance

Nov 19 '05 #4

P: n/a
John, thanks so much for replying, I can't believe you're in work and sending
such long replies :)
That has helped a great deal, but one last thing, you said that session is
valid for only one user logged in, does that mean that each user can have
their own session, and each session can only be viewed by the one user?
Thanks again :)

"John M Deal" wrote:
I really wish I had more time to get into this in depth, but I'm at work
right now so I'll have to keep this short and rely on your ability to
run with this info.

In ASP.Net (and classic ASP for that matter) there are a number of
intrinsic/built-in object provided globally by the environment itself.
Included in these objects is Response (the object that can send data
back to the client), Request (the object that contains the data sent
from the client to the server), Application (an object that can store
globally available data), and Session (an object that can store user
specific data). There are others but these will get you started. You
do not need to create these objects, you simply need to refer to them in
your code.

Now in your case you are reading and writing everything to the database,
so my original notes may not apply in your situation, you'll have to
decide that. However if you do decide to try and follow what I said
before you should know a couple of things.

First Application is created when the web application first starts up
and is available until the web application shuts down. You can catch
events that tell you when these happen in the Global.asax file(s).
You'll want to look into this because if you don't prepare your code for
it data may disappear during long periods of user inactivity and you may
want to reload it when the application reloads. The Application object
can be accessed by any of the connections/threads that are currently
active on the server. This means that you need to lock the access to the
Application object when modifying its contents so you don't run into
threading problems; to do this use Application.Lock() before you add
something to it and Application.Unlock() after you are done with it. Any
page that works with the Application object will be using data that is
available to all users connected to the system.

Second, there is the Session object. By default session only lasts
twenty minutes from the last time a user accessed the system (the server
does not have any other way to know if the user is still connected other
than if they make a request). This time limitation can be controlled in
the web.config file for the site. Session is only valid for a single
user connected to the system, however be aware that if the user opens
two separate browsers each one will have its own session (unless one was
launched from another then they share the same session). Session uses a
cookie by default to track an unique id that is used to retrieve data
for the specific user that it is associated to. When you store object
instances in Session they are only stored for (and retrievable by) the
browser instance associated to the unique id. Session can be made to
not require cookies (but then it puts the unique id in the querystring
for the page). Also Session can be configured to store its data in
memory (InProc) in an out of process Service (StateServer) or in an
external database (SqlServer). This is controlled by your web.config
file for the website (as is the session timeout). If you choose to
store session anywhere besides InProc (the default) you will have to
makes sure any object that you store in it is serializable or the system
will throw an exception (it uses serialization to marshal the object
across the process boundary between the site and the storage repository).

Now that all being said. Whether you use Application or Session you
store instances of objects (or primitives if you want) using a
name/value methodology. For example if you have an instance of an User
object called myUser and you want to put it in session you would do
something like (C# code):

Session["TheUserObjectKey"] = myUser;

To retrieve this you would do something like:

User myUser = (User) Session["TheUserObjectKey"];

This would work the same for the Application though you'd want to do the
Lock/Unlock pattern that I mentioned before. Also note that because
Application and Session store the base Object type you have to cast your
object back to the appropriate type when retrieving them back out.

Ok, that ran a bit longer than I thought it would but it is the basics
of how these objects work. Now if you want to store objects for the
users, you will want to see if their Session has an instance of your
data object, if it doesn't you'd query it from the database then put it
in Session, if it does you'll want to retrieve it from session and
display the appropriate values. Obviously you'll have to deal with the
issues involved with updating these data objects (if that is necessary
for your circumstances) and also you must realize that because
Application and Session have timeouts you will have objects hanging out
in memory until they expire (and then until the GC collects the object)
but this is standard for ASP.Net applications.

Hopefully this is enough to get you started. See the help files and
MSDN online documentation for more information. If you are looking to
do enterprise development in ASP.Net I'd really recommend that you
pickup a good ASP.Net book (search this newsgroup I'm sure you'll find
plenty of recommendations). Also there are some webcasts being done on
ASP.Net out on Microsoft's site that might give you some pointers. Hope
something here helps.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm kinda new to professional asp.net development, so could you just clarify
the application and session objects?
I've got a module that houses many functions that all retrieve information
about their specific table from the database, writing the information into a
'.vb' class file. In effect, i am taking a snapshot of the database at that
current moment and storing it to the class, amending it there and then
writing changes back to the database afterwards. If i understand you
correctly, that is application level, therefore every user's instance of the
application sees the same data, whereas on a session level, each user would
see their own instance. Is this correct? If so, do you have any pointers
about making class files per session, not per application? I'm hugely
confused! The reason i'm developing like this is because i'm migrating an old
VB6 app and web-enabling it using ASP.NET. The old version used classes and i
was expected to re-use as much as possible. I think i understand that the
inherent difference is that with the old app it was installed seperately on
each computer, whereas the ASP.NET version is just one copy, installed on the
web server.
Any help would be gratefully receieved :)

"John M Deal" wrote:

If I'm understanding you correctly you are loading data for the user
from the database then storing that data into application scope. The
issue that you then have is that you retrieve this data from application
scope the next time the page is displayed. If this is the case then you
should modify the way you are handling state management.

The Application object should only be used to store data that is truly
global to every user of the application. If you need to store things on
a per user basis you should look into using the Session object. Using
the Session object will allow you to store data classes on a per user
basis.

If you are worried about running the same query against the database
multiple times, then you might want to abstract the use of the
Application object (not a bad idea in general anyway) so that you can
store a collection of query result sets keyed by the query used, then
retrieve the appropriate result set for each user from the collection.
If the collection doesn't contain the appropriate result set then you
query the database and then add it to the collection and put the
collection back in Application scope. Once you retrieve the appropriate
result set from the application collection you could then put it in the
user's Session object and continue your retrieval from there.

Without more information on how you really intend to use these objects
it is hard to know which solution to use, but hopefully something from
the above will work for you.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:

I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
i have made is running on IIS v6 and consists of a number of pages that allow
the user to read information from the database into classes, which are used
throughout the application. I have made class collections which, upon reading
from the DB, create an instance of the class and store the DB values in
there temporarily. My problem is that if user1 looks at record1, then user2
looks at record2, anything user1 does from that point onwards points the data
at record2.
Is there anything in particular i need to do to make the asp.net application
available to multiple users at the same time, each looking at different
records in the DB?
Thanks in advance

Nov 19 '05 #5

P: n/a
Finally (soooo sorry for carrying on!) is there a way of adding whole classes
to session and reading out of them, or does each variable have to be at
session level?
Cheers again,
Max

"jsale" wrote:
John, thanks so much for replying, I can't believe you're in work and sending
such long replies :)
That has helped a great deal, but one last thing, you said that session is
valid for only one user logged in, does that mean that each user can have
their own session, and each session can only be viewed by the one user?
Thanks again :)

"John M Deal" wrote:
I really wish I had more time to get into this in depth, but I'm at work
right now so I'll have to keep this short and rely on your ability to
run with this info.

In ASP.Net (and classic ASP for that matter) there are a number of
intrinsic/built-in object provided globally by the environment itself.
Included in these objects is Response (the object that can send data
back to the client), Request (the object that contains the data sent
from the client to the server), Application (an object that can store
globally available data), and Session (an object that can store user
specific data). There are others but these will get you started. You
do not need to create these objects, you simply need to refer to them in
your code.

Now in your case you are reading and writing everything to the database,
so my original notes may not apply in your situation, you'll have to
decide that. However if you do decide to try and follow what I said
before you should know a couple of things.

First Application is created when the web application first starts up
and is available until the web application shuts down. You can catch
events that tell you when these happen in the Global.asax file(s).
You'll want to look into this because if you don't prepare your code for
it data may disappear during long periods of user inactivity and you may
want to reload it when the application reloads. The Application object
can be accessed by any of the connections/threads that are currently
active on the server. This means that you need to lock the access to the
Application object when modifying its contents so you don't run into
threading problems; to do this use Application.Lock() before you add
something to it and Application.Unlock() after you are done with it. Any
page that works with the Application object will be using data that is
available to all users connected to the system.

Second, there is the Session object. By default session only lasts
twenty minutes from the last time a user accessed the system (the server
does not have any other way to know if the user is still connected other
than if they make a request). This time limitation can be controlled in
the web.config file for the site. Session is only valid for a single
user connected to the system, however be aware that if the user opens
two separate browsers each one will have its own session (unless one was
launched from another then they share the same session). Session uses a
cookie by default to track an unique id that is used to retrieve data
for the specific user that it is associated to. When you store object
instances in Session they are only stored for (and retrievable by) the
browser instance associated to the unique id. Session can be made to
not require cookies (but then it puts the unique id in the querystring
for the page). Also Session can be configured to store its data in
memory (InProc) in an out of process Service (StateServer) or in an
external database (SqlServer). This is controlled by your web.config
file for the website (as is the session timeout). If you choose to
store session anywhere besides InProc (the default) you will have to
makes sure any object that you store in it is serializable or the system
will throw an exception (it uses serialization to marshal the object
across the process boundary between the site and the storage repository).

Now that all being said. Whether you use Application or Session you
store instances of objects (or primitives if you want) using a
name/value methodology. For example if you have an instance of an User
object called myUser and you want to put it in session you would do
something like (C# code):

Session["TheUserObjectKey"] = myUser;

To retrieve this you would do something like:

User myUser = (User) Session["TheUserObjectKey"];

This would work the same for the Application though you'd want to do the
Lock/Unlock pattern that I mentioned before. Also note that because
Application and Session store the base Object type you have to cast your
object back to the appropriate type when retrieving them back out.

Ok, that ran a bit longer than I thought it would but it is the basics
of how these objects work. Now if you want to store objects for the
users, you will want to see if their Session has an instance of your
data object, if it doesn't you'd query it from the database then put it
in Session, if it does you'll want to retrieve it from session and
display the appropriate values. Obviously you'll have to deal with the
issues involved with updating these data objects (if that is necessary
for your circumstances) and also you must realize that because
Application and Session have timeouts you will have objects hanging out
in memory until they expire (and then until the GC collects the object)
but this is standard for ASP.Net applications.

Hopefully this is enough to get you started. See the help files and
MSDN online documentation for more information. If you are looking to
do enterprise development in ASP.Net I'd really recommend that you
pickup a good ASP.Net book (search this newsgroup I'm sure you'll find
plenty of recommendations). Also there are some webcasts being done on
ASP.Net out on Microsoft's site that might give you some pointers. Hope
something here helps.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm kinda new to professional asp.net development, so could you just clarify
the application and session objects?
I've got a module that houses many functions that all retrieve information
about their specific table from the database, writing the information into a
'.vb' class file. In effect, i am taking a snapshot of the database at that
current moment and storing it to the class, amending it there and then
writing changes back to the database afterwards. If i understand you
correctly, that is application level, therefore every user's instance of the
application sees the same data, whereas on a session level, each user would
see their own instance. Is this correct? If so, do you have any pointers
about making class files per session, not per application? I'm hugely
confused! The reason i'm developing like this is because i'm migrating an old
VB6 app and web-enabling it using ASP.NET. The old version used classes and i
was expected to re-use as much as possible. I think i understand that the
inherent difference is that with the old app it was installed seperately on
each computer, whereas the ASP.NET version is just one copy, installed on the
web server.
Any help would be gratefully receieved :)

"John M Deal" wrote:
>If I'm understanding you correctly you are loading data for the user
>from the database then storing that data into application scope. The
>issue that you then have is that you retrieve this data from application
>scope the next time the page is displayed. If this is the case then you
>should modify the way you are handling state management.
>
>The Application object should only be used to store data that is truly
>global to every user of the application. If you need to store things on
>a per user basis you should look into using the Session object. Using
>the Session object will allow you to store data classes on a per user
>basis.
>
>If you are worried about running the same query against the database
>multiple times, then you might want to abstract the use of the
>Application object (not a bad idea in general anyway) so that you can
>store a collection of query result sets keyed by the query used, then
>retrieve the appropriate result set for each user from the collection.
>If the collection doesn't contain the appropriate result set then you
>query the database and then add it to the collection and put the
>collection back in Application scope. Once you retrieve the appropriate
>result set from the application collection you could then put it in the
>user's Session object and continue your retrieval from there.
>
>Without more information on how you really intend to use these objects
>it is hard to know which solution to use, but hopefully something from
>the above will work for you.
>
>Have A Better One!
>
>John M Deal, MCP
>Necessity Software
>
>jsale wrote:
>
>>I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
>>i have made is running on IIS v6 and consists of a number of pages that allow
>>the user to read information from the database into classes, which are used
>>throughout the application. I have made class collections which, upon reading
>>from the DB, create an instance of the class and store the DB values in
>>there temporarily. My problem is that if user1 looks at record1, then user2
>>looks at record2, anything user1 does from that point onwards points the data
>>at record2.
>>Is there anything in particular i need to do to make the asp.net application
>>available to multiple users at the same time, each looking at different
>>records in the DB?
>>Thanks in advance
>

Nov 19 '05 #6

P: n/a
I guess I kind of got carried away, but it really didn't take as long as
you'd think.

Anyway in response to your question... yes each instance of the browser
is associated to one session object. If the user opens multiple
distinct instances of the browser they will get separate Session object
that their information is stored in, for each instance of the browser.
But for any given browser instance there is only one Session object and
it can be used by all the pages that the user navigates to on the same
website. Note that each ASP.Net website will have its own session
object so if you have two projects on the same server (each in their own
virtual directory) they will each have their own session objects
associated to the browser.

As for multiple users getting to the same Session objects it is
technically possible. This can happen if someone steals the cookie
while it is being transmitted, then uses it to spoof it to the server.
Also if you use cookieless session someone could type the unique id into
their URL and get to someone else's Session. Both of these take
intentional steps on behalf of the "hacker" but it is possible. Also
the session timeout helps with this in that if the user leaves their
browser open the cookie and/or url querystring are only good for 20
minutes (default); though if someone steals the cookie or querystring
they can resubmit to the site to keep the session alive for themselves.
Obviously you should do a threat analysis for this contingency to see if
you care to try and deal with these possibilities.

Hope that didn't confuse things.

John M Deal, MCP
Necessity Software

jsale wrote:
John, thanks so much for replying, I can't believe you're in work and sending
such long replies :)
That has helped a great deal, but one last thing, you said that session is
valid for only one user logged in, does that mean that each user can have
their own session, and each session can only be viewed by the one user?
Thanks again :)

"John M Deal" wrote:

I really wish I had more time to get into this in depth, but I'm at work
right now so I'll have to keep this short and rely on your ability to
run with this info.

In ASP.Net (and classic ASP for that matter) there are a number of
intrinsic/built-in object provided globally by the environment itself.
Included in these objects is Response (the object that can send data
back to the client), Request (the object that contains the data sent
from the client to the server), Application (an object that can store
globally available data), and Session (an object that can store user
specific data). There are others but these will get you started. You
do not need to create these objects, you simply need to refer to them in
your code.

Now in your case you are reading and writing everything to the database,
so my original notes may not apply in your situation, you'll have to
decide that. However if you do decide to try and follow what I said
before you should know a couple of things.

First Application is created when the web application first starts up
and is available until the web application shuts down. You can catch
events that tell you when these happen in the Global.asax file(s).
You'll want to look into this because if you don't prepare your code for
it data may disappear during long periods of user inactivity and you may
want to reload it when the application reloads. The Application object
can be accessed by any of the connections/threads that are currently
active on the server. This means that you need to lock the access to the
Application object when modifying its contents so you don't run into
threading problems; to do this use Application.Lock() before you add
something to it and Application.Unlock() after you are done with it. Any
page that works with the Application object will be using data that is
available to all users connected to the system.

Second, there is the Session object. By default session only lasts
twenty minutes from the last time a user accessed the system (the server
does not have any other way to know if the user is still connected other
than if they make a request). This time limitation can be controlled in
the web.config file for the site. Session is only valid for a single
user connected to the system, however be aware that if the user opens
two separate browsers each one will have its own session (unless one was
launched from another then they share the same session). Session uses a
cookie by default to track an unique id that is used to retrieve data
for the specific user that it is associated to. When you store object
instances in Session they are only stored for (and retrievable by) the
browser instance associated to the unique id. Session can be made to
not require cookies (but then it puts the unique id in the querystring
for the page). Also Session can be configured to store its data in
memory (InProc) in an out of process Service (StateServer) or in an
external database (SqlServer). This is controlled by your web.config
file for the website (as is the session timeout). If you choose to
store session anywhere besides InProc (the default) you will have to
makes sure any object that you store in it is serializable or the system
will throw an exception (it uses serialization to marshal the object
across the process boundary between the site and the storage repository).

Now that all being said. Whether you use Application or Session you
store instances of objects (or primitives if you want) using a
name/value methodology. For example if you have an instance of an User
object called myUser and you want to put it in session you would do
something like (C# code):

Session["TheUserObjectKey"] = myUser;

To retrieve this you would do something like:

User myUser = (User) Session["TheUserObjectKey"];

This would work the same for the Application though you'd want to do the
Lock/Unlock pattern that I mentioned before. Also note that because
Application and Session store the base Object type you have to cast your
object back to the appropriate type when retrieving them back out.

Ok, that ran a bit longer than I thought it would but it is the basics
of how these objects work. Now if you want to store objects for the
users, you will want to see if their Session has an instance of your
data object, if it doesn't you'd query it from the database then put it
in Session, if it does you'll want to retrieve it from session and
display the appropriate values. Obviously you'll have to deal with the
issues involved with updating these data objects (if that is necessary
for your circumstances) and also you must realize that because
Application and Session have timeouts you will have objects hanging out
in memory until they expire (and then until the GC collects the object)
but this is standard for ASP.Net applications.

Hopefully this is enough to get you started. See the help files and
MSDN online documentation for more information. If you are looking to
do enterprise development in ASP.Net I'd really recommend that you
pickup a good ASP.Net book (search this newsgroup I'm sure you'll find
plenty of recommendations). Also there are some webcasts being done on
ASP.Net out on Microsoft's site that might give you some pointers. Hope
something here helps.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
I'm kinda new to professional asp.net development, so could you just clarify
the application and session objects?
I've got a module that houses many functions that all retrieve information
about their specific table from the database, writing the information into a
'.vb' class file. In effect, i am taking a snapshot of the database at that
current moment and storing it to the class, amending it there and then
writing changes back to the database afterwards. If i understand you
correctly, that is application level, therefore every user's instance of the
application sees the same data, whereas on a session level, each user would
see their own instance. Is this correct? If so, do you have any pointers
about making class files per session, not per application? I'm hugely
confused! The reason i'm developing like this is because i'm migrating an old
VB6 app and web-enabling it using ASP.NET. The old version used classes and i
was expected to re-use as much as possible. I think i understand that the
inherent difference is that with the old app it was installed seperately on
each computer, whereas the ASP.NET version is just one copy, installed on the
web server.
Any help would be gratefully receieved :)

"John M Deal" wrote:

If I'm understanding you correctly you are loading data for the user

from the database then storing that data into application scope. The

issue that you then have is that you retrieve this data from application
scope the next time the page is displayed. If this is the case then you
should modify the way you are handling state management.

The Application object should only be used to store data that is truly
global to every user of the application. If you need to store things on
a per user basis you should look into using the Session object. Using
the Session object will allow you to store data classes on a per user
basis.

If you are worried about running the same query against the database
multiple times, then you might want to abstract the use of the
Application object (not a bad idea in general anyway) so that you can
store a collection of query result sets keyed by the query used, then
retrieve the appropriate result set for each user from the collection.
If the collection doesn't contain the appropriate result set then you
query the database and then add it to the collection and put the
collection back in Application scope. Once you retrieve the appropriate
result set from the application collection you could then put it in the
user's Session object and continue your retrieval from there.

Without more information on how you really intend to use these objects
it is hard to know which solution to use, but hopefully something from
the above will work for you.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:
>I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
>i have made is running on IIS v6 and consists of a number of pages that allow
>the user to read information from the database into classes, which are used
>throughout the application. I have made class collections which, upon reading

>from the DB, create an instance of the class and store the DB values in

>there temporarily. My problem is that if user1 looks at record1, then user2
>looks at record2, anything user1 does from that point onwards points the data
>at record2.
>Is there anything in particular i need to do to make the asp.net application
>available to multiple users at the same time, each looking at different
>records in the DB?
>Thanks in advance

Nov 19 '05 #7

P: n/a
Sorry if I didn't make this clear. You can put either instance of
classes or primitive variables in Session/Application because they cast
both types down to the Object type that all items in .Net inherit from.
The best way to see this is to create a simple ASP.Net page and play
with this from a couple of browsers hitting the same website.

John M Deal, MCP
Necessity Software

jsale wrote:
Finally (soooo sorry for carrying on!) is there a way of adding whole classes
to session and reading out of them, or does each variable have to be at
session level?
Cheers again,
Max

"jsale" wrote:

John, thanks so much for replying, I can't believe you're in work and sending
such long replies :)
That has helped a great deal, but one last thing, you said that session is
valid for only one user logged in, does that mean that each user can have
their own session, and each session can only be viewed by the one user?
Thanks again :)

"John M Deal" wrote:

I really wish I had more time to get into this in depth, but I'm at work
right now so I'll have to keep this short and rely on your ability to
run with this info.

In ASP.Net (and classic ASP for that matter) there are a number of
intrinsic/built-in object provided globally by the environment itself.
Included in these objects is Response (the object that can send data
back to the client), Request (the object that contains the data sent
from the client to the server), Application (an object that can store
globally available data), and Session (an object that can store user
specific data). There are others but these will get you started. You
do not need to create these objects, you simply need to refer to them in
your code.

Now in your case you are reading and writing everything to the database,
so my original notes may not apply in your situation, you'll have to
decide that. However if you do decide to try and follow what I said
before you should know a couple of things.

First Application is created when the web application first starts up
and is available until the web application shuts down. You can catch
events that tell you when these happen in the Global.asax file(s).
You'll want to look into this because if you don't prepare your code for
it data may disappear during long periods of user inactivity and you may
want to reload it when the application reloads. The Application object
can be accessed by any of the connections/threads that are currently
active on the server. This means that you need to lock the access to the
Application object when modifying its contents so you don't run into
threading problems; to do this use Application.Lock() before you add
something to it and Application.Unlock() after you are done with it. Any
page that works with the Application object will be using data that is
available to all users connected to the system.

Second, there is the Session object. By default session only lasts
twenty minutes from the last time a user accessed the system (the server
does not have any other way to know if the user is still connected other
than if they make a request). This time limitation can be controlled in
the web.config file for the site. Session is only valid for a single
user connected to the system, however be aware that if the user opens
two separate browsers each one will have its own session (unless one was
launched from another then they share the same session). Session uses a
cookie by default to track an unique id that is used to retrieve data
for the specific user that it is associated to. When you store object
instances in Session they are only stored for (and retrievable by) the
browser instance associated to the unique id. Session can be made to
not require cookies (but then it puts the unique id in the querystring
for the page). Also Session can be configured to store its data in
memory (InProc) in an out of process Service (StateServer) or in an
external database (SqlServer). This is controlled by your web.config
file for the website (as is the session timeout). If you choose to
store session anywhere besides InProc (the default) you will have to
makes sure any object that you store in it is serializable or the system
will throw an exception (it uses serialization to marshal the object
across the process boundary between the site and the storage repository).

Now that all being said. Whether you use Application or Session you
store instances of objects (or primitives if you want) using a
name/value methodology. For example if you have an instance of an User
object called myUser and you want to put it in session you would do
something like (C# code):

Session["TheUserObjectKey"] = myUser;

To retrieve this you would do something like:

User myUser = (User) Session["TheUserObjectKey"];

This would work the same for the Application though you'd want to do the
Lock/Unlock pattern that I mentioned before. Also note that because
Application and Session store the base Object type you have to cast your
object back to the appropriate type when retrieving them back out.

Ok, that ran a bit longer than I thought it would but it is the basics
of how these objects work. Now if you want to store objects for the
users, you will want to see if their Session has an instance of your
data object, if it doesn't you'd query it from the database then put it
in Session, if it does you'll want to retrieve it from session and
display the appropriate values. Obviously you'll have to deal with the
issues involved with updating these data objects (if that is necessary
for your circumstances) and also you must realize that because
Application and Session have timeouts you will have objects hanging out
in memory until they expire (and then until the GC collects the object)
but this is standard for ASP.Net applications.

Hopefully this is enough to get you started. See the help files and
MSDN online documentation for more information. If you are looking to
do enterprise development in ASP.Net I'd really recommend that you
pickup a good ASP.Net book (search this newsgroup I'm sure you'll find
plenty of recommendations). Also there are some webcasts being done on
ASP.Net out on Microsoft's site that might give you some pointers. Hope
something here helps.

Have A Better One!

John M Deal, MCP
Necessity Software

jsale wrote:

I'm kinda new to professional asp.net development, so could you just clarify
the application and session objects?
I've got a module that houses many functions that all retrieve information
about their specific table from the database, writing the information into a
'.vb' class file. In effect, i am taking a snapshot of the database at that
current moment and storing it to the class, amending it there and then
writing changes back to the database afterwards. If i understand you
correctly, that is application level, therefore every user's instance of the
application sees the same data, whereas on a session level, each user would
see their own instance. Is this correct? If so, do you have any pointers
about making class files per session, not per application? I'm hugely
confused! The reason i'm developing like this is because i'm migrating an old
VB6 app and web-enabling it using ASP.NET. The old version used classes and i
was expected to re-use as much as possible. I think i understand that the
inherent difference is that with the old app it was installed seperately on
each computer, whereas the ASP.NET version is just one copy, installed on the
web server.
Any help would be gratefully receieved :)

"John M Deal" wrote:

>If I'm understanding you correctly you are loading data for the user

>from the database then storing that data into application scope. The

>issue that you then have is that you retrieve this data from application
>scope the next time the page is displayed. If this is the case then you
>should modify the way you are handling state management.
>
>The Application object should only be used to store data that is truly
>global to every user of the application. If you need to store things on
>a per user basis you should look into using the Session object. Using
>the Session object will allow you to store data classes on a per user
>basis.
>
>If you are worried about running the same query against the database
>multiple times, then you might want to abstract the use of the
>Application object (not a bad idea in general anyway) so that you can
>store a collection of query result sets keyed by the query used, then
>retrieve the appropriate result set for each user from the collection.
>If the collection doesn't contain the appropriate result set then you
>query the database and then add it to the collection and put the
>collection back in Application scope. Once you retrieve the appropriate
>result set from the application collection you could then put it in the
>user's Session object and continue your retrieval from there.
>
>Without more information on how you really intend to use these objects
>it is hard to know which solution to use, but hopefully something from
>the above will work for you.
>
>Have A Better One!
>
>John M Deal, MCP
>Necessity Software
>
>jsale wrote:
>
>
>>I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app
>>i have made is running on IIS v6 and consists of a number of pages that allow
>>the user to read information from the database into classes, which are used
>>throughout the application. I have made class collections which, upon reading
>
>>from the DB, create an instance of the class and store the DB values in
>
>>there temporarily. My problem is that if user1 looks at record1, then user2
>>looks at record2, anything user1 does from that point onwards points the data
>>at record2.
>>Is there anything in particular i need to do to make the asp.net application
>>available to multiple users at the same time, each looking at different
>>records in the DB?
>>Thanks in advance
>

Nov 19 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.