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.
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?
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.
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.
Do you mean the CPU is going to 100% when you say "thread locking"?
This is a good thread to read though -
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.
That seems like that has to be it, checking it out, Thanks!!!!
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.
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.
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.
Copyright (c) Marimer LLC