Vibrant discussion about CSLA .NET and using the framework to build great business applications.
It seems that the content of ApplicationContext.ClientContext disappear . During the login proess i put the user id in the clientContext, then i use my implementation of IAuthorizeDataPortal to recreate the user and get the stuff i need from it. Now this is working fine for a couple of back and forth and than suddenly no more userID in the ClientContext, this can happen at any time, i there seems to have no pattern.
By reading the previous post, a recurring anwser is make sure you have the csla web in the folder, and i do.
i'm using Win8 with CSLA Core.4.5.30. on .net 4.5
Digging more into this issue i realized that CSLA seems to be dropping the ClientContext when calling a DataPortal inside another DataPortal
Csla.ApplicationContext.ClientContext[Key] = "SomeData"
Csla.ApplicationContext.ClientContext[Key2] = "SomeOtherData"
Csla.ApplicationContext.ClientContext has 2 item
Get Data from a database
private void Child_Fetch(somecriteria)
Csla.ApplicationContext.ClientContext is empty (Sometimes)
Anybody seen this before?
Are you sure the ClientContext is till present after data access from database?
If you have async or tasks in the data access that would explain how the code could be running on another thread and hence has lost the application context.
DataPortal.FetchChild does NOT use task or async and does not interact with ApplicationContext.
The semenatics of DataPortal.FetchChild is:
Another culprit may be if you have async/tasks in one of the other methods that may be called.
Jonny Bekkum, Norway
Givin that how do I get it back? I need the clientcontext all the way down to the DataPortal.FetchChild
I do have Async Tasks in some methods and I do need the client context, can I do something to keep it?
The clientcontext is attached to the primary thread. If you somehow make a call that ends up running on another thread it is up to you to copy the clientcontext from the original thread to the new thread.
A typical async/await call won't actually jump threads btw - but if you do Task.Run or something along that line the result would be a new thread.
Do you use the Csla.Threading.CslaTaskScheduler when you run tasks?
I'm Only using Async/Await and by adding the CSLA code to MY project to see what's going on, I see that at the beginning of the CSLA stack the ClentContext is there but than a bit later it disappear for some reason.
As you can see in the picture I do have the ClientContext.
Here is the steps
1. I use DataPortal_Fetch to get my Invoice
2. I Add a Part on it, doing this triggers an Async Business rule
2.1 That calls a DataPortal_Execute (a Command)
2.2 That command Load the part again (DataPortal_Fetch) but this time in edit mode so it can set some missign attributes
When I'm Loading the properties of the last Fetch - The context is lost,
In the picture included here you can see the CSLA call stack.
Am I doing something wrong?
I'm using a lot of Async business Rules and it seems to be happening more in them!!!
All your code (1 through 2.2) is 100% server-side?
1. Is from the UI , It call the server to get the list of Invoices
but the rest is all server side.
So your Part object is a child of something like Invoice.PartList, but is also a root object in that it has a DataPortal_Fetch method (not just a Child_Fetch)?
Also, is the async rule that is run in the Part object a per-type or per-property rule? What triggers this rule to run when the object is created?
That's right, we use it as both a child and a Root object.
These rules are per-property rules.
We use BusinessRules.CheckRules(PartTypeProperty);
So it loads a list immediately for the user to select, to set another property.
So you use use a rule to do lazy loading of a property?