Static Class - Thread Safe?

R

reyesflaco

I am developing an application using asp.net 2.0. I created all my
business objects in my app_code folder. As of right now, all my
classes are public.

In my aspx pages, I am declaring the class like so

static Person myPerson;

The static declaration is working for me, for It keeps the instance of
the class open through the lifetime of the user who is logged in.
However, I read that the reference remains open even after the user's
session, and it is probably not going to be thread safe? I want to
avoid storing it in a Session due to it being rather expensive on the
server. I could probably make the class private, and ensure that the
class is instantiated accordingly. Any suggestions from you experts?
 
H

Hans Kesting

I am developing an application using asp.net 2.0. I created all my
business objects in my app_code folder. As of right now, all my
classes are public.

In my aspx pages, I am declaring the class like so

static Person myPerson;

Do NOT do that, as all users will share the same "Person" instance!
And I doubt that that is what you want.
Use Session to store personal data.

Hans Kesting
 
S

Samuel R. Neff

Session is a lot less "expensive" than a static variable. Sessions
expire and get cleared out, statics don't (not until aspnet recycles).

Sam
 
G

Guest

I'm not sure I'd agree with a kind of blanket statement like that, since
there is considerably more overhead in simply creating a session item than
populating a static variable. The main issue here is that the OP is using
static objects which means that every user will have the same "person" object
- which is *not* what he wants.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com
 
J

John Saunders [MVP]

Peter Bromberg said:
I'm not sure I'd agree with a kind of blanket statement like that, since
there is considerably more overhead in simply creating a session item than
populating a static variable. The main issue here is that the OP is using
static objects which means that every user will have the same "person"
object
- which is *not* what he wants.

Additionally, many developers like the OP need to be aware of the need for
synchronization when using static variables in a web application or web
service. When multiple requests arrive at the same time, they will each be
referencing the same data at the same time. If the data is being updated,
then it needs to be protected by a lock of some kind.

So, in general, don't use statics in an ASP.NET application, unless you
_really_ know what you're doing. And then, I suggest you clearly document
the fact that you _do_ know what you're doing, otherwise the next developer
to see the code might just remove the statics!
 
S

Samuel R. Neff

But the synchronization issue is the same with any shared variable,
whether it's shared via a static member, a session variable,
application variable, cache, or anything else.

The OP is putting a Peson object in a static so in switching to
session he'll surely put the Person object in the session. An
individual user can easily send multiple requests (different browser
windows, tabs, or if using ajax, or hitting refresh quickly) which
would cause multiple asp.net requests to be processed at the same time
and working with the same Person variable. Thus if the Person content
is changed, all accesses to Person need to be synchronized.

Sam
 
G

George Ter-Saakov

You are safe with Sessions.
Session is locked per request. Meaning even if person hit 2 buttons quickly
(for the same session) he will have second request on hold by .NET untill
first finished.

So you do not need to sync access to objects you keep in Session.

George.
 
S

Samuel R. Neff

George,

The docs say HttpSession is:

Any public static (Shared in Visual Basic) members of this type are
thread safe. Any instance members are not guaranteed to be thread
safe.

And reviewing relevant parts in Reflector don't show any cross-request
locking. If you're right, that's great, but can you back it up with a
reference?

Even if you are right about session access, if the object in the
session is a complex object then you need to sync access to it's
properties as in the OP's case.

Sam
 
G

George Ter-Saakov

"if the object in the session is a complex object then you need to sync
access to it's properties as in the OP's case."

ASP.NET guarantees you that only one thread at a time will access Session,
hence the object that is kept inside of the Session.
So really no need to sync access.
-------------------------------------------------
As far as cross-requests and reflection just do a Google search "ASP.NET
session locking"
you will come across bunch of articles.

One of them
(http://odetocode.com/Blogs/scott/archive/2006/05/20/3648.aspx )
say
"To prevent two pages from modifying in-process Session variables at the
same time, the ASP.NET runtime uses a lock. When a request arrives for a
page that reads and writes Session variables, the runtime acquires a writer
lock. The writer lock will block other pages in the same Session who might
write to the same session variables. "

I bet you can find similar thing in MSDN. Actually Session locking was
there forever from plain asp.


George
 

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

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top