Static Class - Thread Safe?

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

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

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On Thu, 19 Jul 2007 05:26:10 -0700, "re********@yahoo.com"
<re********@yahoo.comwrote:

>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?

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

"Samuel R. Neff" wrote:

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

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On Thu, 19 Jul 2007 05:26:10 -0700, "re********@yahoo.com"
<re********@yahoo.comwrote:

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?

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
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Fri, 20 Jul 2007 11:02:01 -0400, "George Ter-Saakov"
<gt****@cardone.comwrote:

>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.

"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/arc...5/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


"Samuel R. Neff" <sa********@nomail.comwrote in message
news:d3********************************@4ax.com...

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
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Fri, 20 Jul 2007 11:02:01 -0400, "George Ter-Saakov"
<gt****@cardone.comwrote:

>>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.

PS: Actually found it on MSDN
http://msdn.microsoft.com/msdnmag/issues/05/09/WebQA/

The last question on the bottom

George.
"George Ter-Saakov" <gt****@cardone.comwrote in message
news:uJ*************@TK2MSFTNGP04.phx.gbl...

"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/arc...5/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


"Samuel R. Neff" <sa********@nomail.comwrote in message
news:d3********************************@4ax.com...

>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
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Fri, 20 Jul 2007 11:02:01 -0400, "George Ter-Saakov"
<gt****@cardone.comwrote:

>>>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.

Thanks for the links.

Best regards,

Sam
On Thu, 26 Jul 2007 14:59:04 -0400, "George Ter-Saakov"
<gt****@cardone.comwrote:

>PS: Actually found it on MSDN
http://msdn.microsoft.com/msdnmag/issues/05/09/WebQA/

The last question on the bottom

George.

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.