I don't really know how to identify our problem and I hope someone can point us in the right direction. We are developing a CSLA 2.0 based application and during one of our testing cycles we ran into the following issue.
The testers were testing an ASP.NET 2.0 page and managed to generate a run-time exception at virtually the same time. The error is not the problem, but rather what happens after the exception occurs.
The page in question allows a user to update his/her user profile (name, email, etc.). THe page is in a secure authenticated area of the site. After they updated the form, they clicked the "Save" button and got BO exception thrown by the Public Save method of the business object. The runtime exception is trapped by the application and elegantly handled.
Here's the kicker! If they hit the browser refresh or click on the menu "My profile" button to reload the page, both browser sessions display the field values of the user who first clicked submit and thus generated the exception.
We know the exception is thrown by the CanUpdate function from within business object and that problem is easily corrected, but we don't know why the 2 browsers start displaying the values from a different session.
Does anyone have any idea why/how this happens and where to start looking for a solution?
That is certainly quite odd.
There are three easy ways to store cross-user values in ASP.NET: Shared/static fields, System.Web.Caching and the ASP.NET Application object.
The easiest one to accidentally use are Shared/static fields - is it possible that you are putting some value into a static field, thus making it AppDomain-wide, and effectively global to all users?
Also, can you repeat this process, and then have a third browser go to "My profile" (without having hit the exception earlier in this third browser)? It would be interesting to see if all users are affected, or only those that hit the exception.
I agree with Rocky that caching of BOs can be a problem. I tried various ways to cache a Root BO and then pull it out of th cahce, clone it and let a user modify and save it. This BO is expensive to create and I thought caching it would be a good idea.
The problem is that in some scenarios the user's changes would get stored in the cache too. So that when the next user retrieved this BO from cache it was filled out instead of blank. I had thought that cloning it would break the references. But I think the cloning did not go deep enough and that the BOs contained inside this Root BO were still being referenced.
Bottom line for me: Only use ReadOnly BOs in the ASP.Net cache.
Joe
Caching was our first thought as well, but we don't use any explicit caching other that the list objects created by the native CSLA list classes. We also double checked and nono of our objects are declared static or shared.
To Rocky's question, the scenario can be reproduced with as many browsers as we choose and everyone gets the values of the first user to hit the exception, but it only happens if an exception is thrown. We have since fixed the root cuase in our CanUpdate function, so the exception is no longer thrown and therefor the problem has disappeared, but it certainly leaves us wondering.
What if a) a runtime exception is thrown in production and it happens with a customer profile and b) is it a phenomenon with the specific object or can this happen with other objects that may expose private/personal information?
Is there anything in the native CSLA code that can contribute to this problem?
I don't know what CSLA code would cause this, no. Especially given that your exception came from the CanUpdate() method (which I assume is a Shared/static method?), which really isn't a CSLA thing per se, and also the exception would have occurred before the data portal would be invoked.
Are my assumptions there correct? (that the exception comes from your code, and that it happens before the data portal is invoked)
Copyright (c) Marimer LLC