Hi,
as I understand the Csla.Data.ObjectContextManager uses one ObjectContext for multiple threads. According to the following post that can cause problems:
In short:
If you host your Business Layer on a application server several threads can access DataPortal_Insert, DataPortal_Update, etc at the same time. They will all use the same ObjectContext to make there updates to the database.
Regards,
Anders Sidwall
I noticed that too. False alarm on my behalf. That Rocky fellow sure thinks about everything :)
There is one scenario (I can think of) where this might pose a problem.
When CSLA runs inside ASP.NET it can't use thread-local storage (TLS) because that's off limits in ASP.NET. So LocalContext is maintained in HttpContext.Current.
My guess is that if you manually spin up worker threads in ASP.NET you might end up with those threads sharing the same HttpContext, and thus the same LocalContext, and thus the same ObjectContextManager.
In my view that is outside of my scope, and you'll just have to not use ObjectContextManager. Without TLS or a per-thread HttpContext there's no way I know of to store per-thread data, so this problem becomes intractable.
Then again, maybe ASP.NET is smart enough to create a unique HttpContext for each thread you create...
Copyright (c) Marimer LLC