Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Static Class - Thread Safe?

Reply
Thread Tools

Static Class - Thread Safe?

 
 
reyesflaco@yahoo.com
Guest
Posts: n/a
 
      07-19-2007
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?

 
Reply With Quote
 
 
 
 
Hans Kesting
Guest
Posts: n/a
 
      07-19-2007
> 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


 
Reply With Quote
 
 
 
 
Samuel R. Neff
Guest
Posts: n/a
 
      07-19-2007

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, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:

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


 
Reply With Quote
 
=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
Guest
Posts: n/a
 
      07-19-2007
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, "(E-Mail Removed)"
> <(E-Mail Removed)> wrote:
>
> >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?

>
>

 
Reply With Quote
 
John Saunders [MVP]
Guest
Posts: n/a
 
      07-19-2007
"Peter Bromberg [C# MVP]" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> 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!
--
John Saunders [MVP]

 
Reply With Quote
 
Samuel R. Neff
Guest
Posts: n/a
 
      07-20-2007

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


------------------------------------------------------------
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 18:19:36 -0400, "John Saunders [MVP]"
<john.saunders at trizetto.com> wrote:


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

 
Reply With Quote
 
George Ter-Saakov
Guest
Posts: n/a
 
      07-20-2007
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.

"Samuel R. Neff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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
>
>
> ------------------------------------------------------------
> 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 18:19:36 -0400, "John Saunders [MVP]"
> <john.saunders at trizetto.com> wrote:
>
>
>>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!



 
Reply With Quote
 
Samuel R. Neff
Guest
Posts: n/a
 
      07-26-2007
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"
<(E-Mail Removed)> wrote:

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

 
Reply With Quote
 
George Ter-Saakov
Guest
Posts: n/a
 
      07-26-2007
"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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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"
> <(E-Mail Removed)> wrote:
>
>>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.
>>



 
Reply With Quote
 
George Ter-Saakov
Guest
Posts: n/a
 
      07-26-2007
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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"
>> <(E-Mail Removed)> wrote:
>>
>>>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.
>>>

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Thread safety problems with function scope static variables vs class static private members Hicham Mouline C++ 5 12-19-2008 08:10 PM
Why inner class can not have static data, static fields or nested class? Robin Java 0 06-06-2007 11:16 AM
referring to static fields of enclosing class from static inner class? bugbear Java 4 08-23-2006 08:26 AM
Instantiating a static class( Class with all static members - methods and variables) SaravanaKumar Java 6 10-19-2004 08:20 AM
a static local variable in a static method is thread local storage? Patrick Hoffmann C++ 3 08-08-2003 02:37 PM



Advertisments