Threads with ASP.NET

A

Angel

Hi everybody,
I am new to ASP.NET, and my question might be obvious to most of you but I
do not seem to find many things about threads and ASP.NET.

I have an object(Object 1) which need some service from another
object(Object2).
Object 2 has only two methods and no members.

Load(Object1 obj, int id);
Save(Object1 obj);

I will have thousands instances from Object1, but to save memory I will only
have one instance of Object2.
I decided to create only one reference of Object2 and keep it as class
member of Object1 class.

Now if I have only one instance per class, any user logged to the
application (any session) will use the same Object2 obj2 reference.
My question is: Should I make Load() and Save() methods of Object2 thread
safe(Using Lock for example), or ASP.NET will take care of different
sessions(users) accessing this methods.

Again I do not create separate threads. I just wonder if ASP.NET make a
separate thread for any of application users (any session) or it creates a
separate process(with separate allocated memory ) per session and this
process memory area is guarded from other processes.

Thanks
 
S

Steve Drake

I presume you are using a singleton pattern, I always lock when writing and
depending on the object type lock when reading aswell.

remember, ASP.NET is stateless, yes you can create a object that sits around
but ASP.NET could kill it when it gets recycled and you don't get any
warning of this, so if you are saving things in memory that you need to keep
then watch out.

Steve
 
A

Angel

Thanks Steve,
You got it right. I use something as singleton. I have one object per
class.
Let say my user is Student
When user login I create a UserObject that I save in Session["User"].
Then on demand I fill its collection properties student classes ,
teachers.... Any of those collections have a class reference to a
DataPersistObject instance.
Every class of those collection properties has a class reference to an
object (DataPersistObject ) which has only 2 methods
Load(obj, id) and Save(obj), they retrieve or save one object per time from
a database to collection and vice versa.
The problem is that I do not know how different sessions will interact
(behave) when accessing the methods of this object.
Should I synchronize "Load" and "Save" methods using "lock(this)" within
the methods body , or ASP.Net will take care of this concurrent access to
this methods between different sessions.

When the user logout all this will be released since the only place keeping
reference to this properties is UserObject, which is released when
session["User is released"].

My guess is that class references to my DataPersist object would not be
released until Application is running, because they have been created with
Static constructor like this:

static Teachers()
{
//fdmobj is defined in the base class
fdmobj = new DMTeacher();

}


Angel
 
S

Scott Allen

Hi Angel:

If the Load and Save methods are stateless, then you don't need to
worry about locking. A stateless method will use only local variables
and parameters to the method. You should consider making the methods
static, then all of your object1 instances won't even need to store a
reference to object2.

You are correct in thinking ASP.NET will use multiple threads to
service incoming requests. It won't prevent thread unsafe code from
bad bahvior.
 
A

Angel

I was thinking of doing this methods static and now when you mentioned it I
think that this is better idea anyway.
I did not made them static originally because I've had an idea to keep some
values there.
Later I realized that this will give me only troubles and give it up.
Thanks
Angel
 
M

Mike Newton

Yeah...

With the archetecture of ASP.NET, I imagine that the only way to
preserve an object across many sessions is by creating an actual windows
service that preserves the state of the object. If this were the case,
then you would just have a queue of items waiting on this service, which
would negate any cross-access issues. Of course, it's probably way
easier to just use static functions, like stated somewhere else in this
thread.

Mike

Thanks Steve,
You got it right. I use something as singleton. I have one object per
class.
Let say my user is Student
When user login I create a UserObject that I save in Session["User"].
Then on demand I fill its collection properties student classes ,
teachers.... Any of those collections have a class reference to a
DataPersistObject instance.
Every class of those collection properties has a class reference to an
object (DataPersistObject ) which has only 2 methods
Load(obj, id) and Save(obj), they retrieve or save one object per time from
a database to collection and vice versa.
The problem is that I do not know how different sessions will interact
(behave) when accessing the methods of this object.
Should I synchronize "Load" and "Save" methods using "lock(this)" within
the methods body , or ASP.Net will take care of this concurrent access to
this methods between different sessions.

When the user logout all this will be released since the only place keeping
reference to this properties is UserObject, which is released when
session["User is released"].

My guess is that class references to my DataPersist object would not be
released until Application is running, because they have been created with
Static constructor like this:

static Teachers()
{
//fdmobj is defined in the base class
fdmobj = new DMTeacher();

}


Angel





I presume you are using a singleton pattern, I always lock when writing
and

depending on the object type lock when reading aswell.

remember, ASP.NET is stateless, yes you can create a object that sits
around

but ASP.NET could kill it when it gets recycled and you don't get any
warning of this, so if you are saving things in memory that you need to
keep

then watch out.

Steve


I

thread

creates
 
A

Angel

Of course, it's probably way
easier to just use static functions, like stated somewhere else in this
thread.

True, except if one tries to utilize objects polymorphic behavior.
Static methods cannot be virtual.
 
A

Alvin Bruney [MVP]

With the archetecture of ASP.NET, I imagine that the only way to preserve
an object across many sessions is by creating an actual windows service
that preserves the state of the object.

no, it's not the only way. and your approach isn't recommended either since
a windows service is not guaranteed to be running when your application
runs. the cache object shares state across sessions, also the static
modifier implements one copy per appdomain which is shared across sessions.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Mike Newton said:
Yeah...

With the archetecture of ASP.NET, I imagine that the only way to preserve
an object across many sessions is by creating an actual windows service
that preserves the state of the object. If this were the case, then you
would just have a queue of items waiting on this service, which would
negate any cross-access issues. Of course, it's probably way easier to
just use static functions, like stated somewhere else in this thread.

Mike

Thanks Steve,
You got it right. I use something as singleton. I have one object per
class.
Let say my user is Student
When user login I create a UserObject that I save in Session["User"].
Then on demand I fill its collection properties student classes ,
teachers.... Any of those collections have a class reference to a
DataPersistObject instance.
Every class of those collection properties has a class reference to an
object (DataPersistObject ) which has only 2 methods
Load(obj, id) and Save(obj), they retrieve or save one object per time
from
a database to collection and vice versa.
The problem is that I do not know how different sessions will interact
(behave) when accessing the methods of this object.
Should I synchronize "Load" and "Save" methods using "lock(this)" within
the methods body , or ASP.Net will take care of this concurrent access to
this methods between different sessions.

When the user logout all this will be released since the only place
keeping
reference to this properties is UserObject, which is released when
session["User is released"].

My guess is that class references to my DataPersist object would not be
released until Application is running, because they have been created
with
Static constructor like this:

static Teachers()
{
//fdmobj is defined in the base class
fdmobj = new DMTeacher();

}


Angel





I presume you are using a singleton pattern, I always lock when writing
and

depending on the object type lock when reading aswell.

remember, ASP.NET is stateless, yes you can create a object that sits
around

but ASP.NET could kill it when it gets recycled and you don't get any
warning of this, so if you are saving things in memory that you need to
keep

then watch out.

Steve


Hi everybody,
I am new to ASP.NET, and my question might be obvious to most of you but
I

do not seem to find many things about threads and ASP.NET.

I have an object(Object 1) which need some service from another
object(Object2).
Object 2 has only two methods and no members.

Load(Object1 obj, int id);
Save(Object1 obj);

I will have thousands instances from Object1, but to save memory I will

only

have one instance of Object2.
I decided to create only one reference of Object2 and keep it as class
member of Object1 class.

Now if I have only one instance per class, any user logged to the
application (any session) will use the same Object2 obj2 reference.
My question is: Should I make Load() and Save() methods of Object2
thread

safe(Using Lock for example), or ASP.NET will take care of different
sessions(users) accessing this methods.

Again I do not create separate threads. I just wonder if ASP.NET make a
separate thread for any of application users (any session) or it
creates

a

separate process(with separate allocated memory ) per session and this
process memory area is guarded from other processes.

Thanks
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top