CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • CSLA.NET object stored in ASP.NET session

    rated by 0 users
    Answered (Verified) This post has 4 verified answers | 10 Replies | 4 Followers

    Not Ranked
    8 Posts
    zbend posted on Fri, Mar 29 2013 11:11 AM

    I've inherited an ASP.NET MVC project that uses CSLA. Its storing a couple CSLA objects in session, I think this may be part of the problems its running into with hanging\thread locking, but I'm not sure how to explain and convince people that, this is the case so we can make the investment in reworking that. Basically am I right? Or what are commin scenarios or miss uses of CSLA with ASP.NET that can lead to thread locking and such? Any help is appreciated!! Thanks.

    Answered (Verified) Verified Answer

    Top 10 Contributor
    718 Posts
    Verified by zbend

    This is a good thread to read though -

    http://forums.lhotka.net/forums/t/11836.aspx

    The short answer is that our solution which resolved the 100% cpu spikes was simply to override CanReadProperty to return true (not base behavior).  I may be missing something as a colleague made the changes and got more into this.  Jaans (think it was him) reproduced the issue and you can see the repro video in that thread.

    Top 10 Contributor
    4,106 Posts
    Answered (Verified) Andy replied on Sat, Mar 30 2013 10:57 AM
    Verified by zbend

    The site I'm doing this in is not heavy load, but I've been storing Csla objects in Asp.Net sessions without any issue.  In general you should be fine as each Asp.Net request is served by a single thread, so unless you're doing multiple Ajax calls which end up pulling the object out of session and changing values, you should be ok.  You may want to include more information about the scenario where you're encountering an issue.

    Top 10 Contributor
    9,475 Posts
    Verified by zbend

    There are no problems putting CSLA objects into Session. That is a supported scenario that has been working since 2001.

    There ARE problems with any scenario where a CSLA object instance is used from multiple threads at the same time. That is NOT a supported scenario. Like the majority of the .NET framework, CSLA is not threadsafe (except in very specific cases).

    If you are trying to use the same object instances from multiple threads you will need to rethink your implementation to avoid such a situation.

    Rocky

    Not Ranked
    8 Posts
    Answered (Verified) zbend replied on Sat, Mar 30 2013 12:38 PM
    Verified by zbend

    So what skagen00 pointed too was my real problem, but since I did ask about storing CSLA objects in session and that is fine (although maybe not the best practice) I also marked Rocky's answer. Simply overriding the CanReadProperty appears to have resolved this for me, it appears to be that you don't have to do anything special but use a ReadOnlyBase object in an ASP.NET app and you would have this issue under load.

    All Replies

    Not Ranked
    10 Posts

    Hi zbend,

    I dont know the exact scenario of course, but as csla is not threadsafe it might be the cause.

    Maybe not explain, but prove it? An possible option is to store a simple dto instead of an bo?

    I wonder though, why store a whole csla in the session in the first place? What are you trying to accomplish?

    could you provide us with more info please?

     

    colour haze

    Top 10 Contributor
    718 Posts

    Do you mean the CPU is going to 100% when you say "thread locking"? 

    Not Ranked
    8 Posts
    zbend replied on Fri, Mar 29 2013 7:36 PM

    Yes.

    Not Ranked
    8 Posts
    zbend replied on Fri, Mar 29 2013 7:41 PM

    I may just have to prove it, it will just a take a fair amount of reworking and then putting it under proper load to reproduce it. Its a project I've inherited with many imperfections to put it nicely, as far as I can tell its stored in session just to avoid loading it from the db each request which I think would be better here. I know session is copied for each asp.net thread but I'm guessing that still doesn't jive with the unique way csla operates? Thanks.

    Not Ranked
    10 Posts

    Hi zbend,

    I don't know if the session is programmed as an abstraction used via an interface or just by its concrete class. Perhaps you could make it easier by applying an adapter pattern. This way you can program against an interface and maybe divide the transition into smaller portions, like per ER, where you can simply move from session to database.

     

    Top 10 Contributor
    718 Posts
    Verified by zbend

    This is a good thread to read though -

    http://forums.lhotka.net/forums/t/11836.aspx

    The short answer is that our solution which resolved the 100% cpu spikes was simply to override CanReadProperty to return true (not base behavior).  I may be missing something as a colleague made the changes and got more into this.  Jaans (think it was him) reproduced the issue and you can see the repro video in that thread.

    Not Ranked
    8 Posts
    zbend replied on Sat, Mar 30 2013 10:14 AM

    That seems like that has to be it, checking it out, Thanks!!!! 

    Top 10 Contributor
    4,106 Posts
    Answered (Verified) Andy replied on Sat, Mar 30 2013 10:57 AM
    Verified by zbend

    The site I'm doing this in is not heavy load, but I've been storing Csla objects in Asp.Net sessions without any issue.  In general you should be fine as each Asp.Net request is served by a single thread, so unless you're doing multiple Ajax calls which end up pulling the object out of session and changing values, you should be ok.  You may want to include more information about the scenario where you're encountering an issue.

    Top 10 Contributor
    9,475 Posts
    Verified by zbend

    There are no problems putting CSLA objects into Session. That is a supported scenario that has been working since 2001.

    There ARE problems with any scenario where a CSLA object instance is used from multiple threads at the same time. That is NOT a supported scenario. Like the majority of the .NET framework, CSLA is not threadsafe (except in very specific cases).

    If you are trying to use the same object instances from multiple threads you will need to rethink your implementation to avoid such a situation.

    Rocky

    Not Ranked
    8 Posts
    Answered (Verified) zbend replied on Sat, Mar 30 2013 12:38 PM
    Verified by zbend

    So what skagen00 pointed too was my real problem, but since I did ask about storing CSLA objects in session and that is fine (although maybe not the best practice) I also marked Rocky's answer. Simply overriding the CanReadProperty appears to have resolved this for me, it appears to be that you don't have to do anything special but use a ReadOnlyBase object in an ASP.NET app and you would have this issue under load.

    Page 1 of 1 (11 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems