Hi,
I am having a problem with the ClientContext.
I am using CSLA 4.1.0 for Silverlight.
I've had this problem before and I thought I fixed it but it keeps coming back.
It is a problem with the async DataPortal.
I believe the problem occurs when there is more than one simultaneous call to the DataPortal - for example when multiple Silverlight ViewModels refresh at the same time.
When my app starts up and the user logs in, on the Silverlight side I store several values in the ClientContext.
For example the current language id, timezone id, stuff like that.
This stuff gets written to the ClientContext very early on.
The values are definitely in there, and they are put there from the Silverlight side.
These values are then read on the server side in many places in the code.
Now the app will work perfectly 90% of the time, but if you thrash it, it ends up crashing with the fault that the desired key is not found in the ClientContext dictionary.
The problem always happens in the server side code.
When the problem occurs, the number of items in the ClientContext is 0 i.e. it has been cleared.
I am sure it is a threading issue, I think somehow one thread returns and clears out its ClientContext and this affects the other thread (somehow).
The first time this problem occured I think it was because I was missing a reference to Clsa.Web.dll in my server project.
This is not the case this time.
Has anyone any idea of what might be wrong?
I am hoping I am missing some simple configuration setting or something.
Bear in mind the code works 90% of the time, and the point where it loses the ClientContext is random.
I am really in need of help, I have a demo due on Friday and my app keeps crashing on me!
Any help greatly appreciated!
My assumption is that the problem is caused by client side code.
1. Please check that your code does not use the System.ComponentModel.BackgroundWorker. We created our own Csla.Threading.BackgroundWorker to in order to transfer:
to the background thread. The the System.ComponentModel.BackgroundWorker will not transfer these and such it will appear that the ClientContext has been cleared. The DataPortal async methods has its own implementation to transfer these parameters.
2. If your servercode uses a System.ComponentModel.BackgroundWorker (in f.ex Async rules) the rule may experiance that the context is cleared if the result is returned before the rule is completed.
The Csla.Server.Hosts.Silverlight.SilverlightRequestProcessor will set the context before calling any method on the BO and clear the context in the finally pert of method. Any running async rules on the server will then have a "cleared" context.
3. In order to debug - add the Csla code to you project and write to the debug / trace window when ApplicationContext.Clear is called to determine if this is called on "bad" place or if it is a BackgroundWorker thatis causing the problem.
Hi Jonny,
I am using Csla.Threading.BackgroundWorker, not System.ComponentModel.BackgroundWorker.
After some more investigation I found that the ApplicationContextManager is starting out as a Csla.Web.ApplicationContextManager, but it is later switching to a Csla.ApplicationContextManager. This happens because the HttpContext.Current becomes null.
If I remove the BackgroundWorker code, the switch of ContextManager does not happen.
So I assume the Csla.Threading.BackgroundWorker is causing the HttpContext.Current to become null?
Can you confirm that the switching of the ContextManager should not normally happen?
From looking at the code it looks like that once it switches it is never going to switch back.
I am accessing the ClientContext from the BackgroundWorker code. Perhaps it is not possible to do this for a Silverlight app?
Please note I was perfoming these tests using Cassini.
Looking at an old post, (http://forums.lhotka.net/forums/p/2811/14404.aspx), Rocky seems to indicate the Cassini may be broken in this regard??
I will do some further testing tomorrow on IIS rather than Cassini.
Thanks for your help.
Hi Richard,
That means that you are using the background worker on the serverside.
Yes, there was a bug in Csla concerning context switcing for BackgroundWorkers and HttpContext.
Look at the changes ApplicationContext.cs in Csla 4.2.
Hi Jonny,
Yes we are using the CSLA background worker on the server side.
I had a look at the ApplicationContext code in CSLA 4.2 as you suggested.
I switched my app over to CSLA 4.2 and the problem went away when running under Cassini.
However when I deployed my app to IIS the problem was still present.
I am investigating further and will let you know what I find.
Hi Richard,
Make sure Csla.Web is present in the bin folder on your IIS application.
You may also consider to upgrade to IIS 7.5 Express on your dev-macine (you can switch back and forth from Cassini to IIS Express) and can even install the IIS Express on both Win7, Vista and Win XP.
Hi Jonny,
I tested again on my dev machine with CSLA 4.2 on both IIS and IIS Express and was unable to reproduce the problem.
However the test was still failing on our build machine. I then installed the latest build of CSLA 4.2 on the build machine and the problem went away.
The only possibility I can think of is that maybe the build machine had an earlier beta version of CSLA 4.2 installed!
Problem solved touch wood!
Thanks for your help.
Copyright (c) Marimer LLC