Static Class - Thread Safe?

Discussion in 'ASP .Net' started by reyesflaco@yahoo.com, Jul 19, 2007.

  1. Guest

    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?
    , Jul 19, 2007
    #1
    1. Advertising

  2. Hans Kesting Guest

    > 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
    Hans Kesting, Jul 19, 2007
    #2
    1. Advertising

  3. 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, ""
    <> 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?
    Samuel R. Neff, Jul 19, 2007
    #3
  4. 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, ""
    > <> 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?

    >
    >
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=, Jul 19, 2007
    #4
  5. "Peter Bromberg [C# MVP]" <> wrote
    in message news:...
    > 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]
    John Saunders [MVP], Jul 19, 2007
    #5
  6. 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!
    Samuel R. Neff, Jul 20, 2007
    #6
  7. 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" <> wrote in message
    news:...
    >
    > 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!
    George Ter-Saakov, Jul 20, 2007
    #7
  8. 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"
    <> 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.
    >
    Samuel R. Neff, Jul 26, 2007
    #8
  9. "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






    "Samuel R. Neff" <> wrote in message
    news:...
    > 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"
    > <> 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.
    >>
    George Ter-Saakov, Jul 26, 2007
    #9
  10. 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" <> wrote in message
    news:...
    > "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
    >
    >
    >
    >
    >
    >
    > "Samuel R. Neff" <> wrote in message
    > news:...
    >> 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"
    >> <> 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.
    >>>

    >
    >
    George Ter-Saakov, Jul 26, 2007
    #10
  11. Thanks for the links.

    Best regards,

    Sam


    On Thu, 26 Jul 2007 14:59:04 -0400, "George Ter-Saakov"
    <> wrote:

    >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.
    Samuel R. Neff, Jul 27, 2007
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. S
    Replies:
    2
    Views:
    3,914
  2. Oleg Ogurok
    Replies:
    1
    Views:
    371
    Kevin Spencer
    Jun 18, 2004
  3. dee
    Replies:
    11
    Views:
    2,817
  4. Gabriel Rossetti
    Replies:
    0
    Views:
    1,297
    Gabriel Rossetti
    Aug 29, 2008
  5. John Nagle
    Replies:
    5
    Views:
    452
    John Nagle
    Mar 12, 2012
Loading...

Share This Page