I noticed that the ConnectionManager issues a lock on a static object in the GetManager() call, which on first run calls the constructor that in turns calls Open() on the new connection, a potentially "long" operation.
This seems to create a bottleneck on a busy web site, when GetManager gets called from many threads at the same time. In this scenario I don't see a need for locking, as all requests are running on their own thread (read; having their own private LocalContext - HttpContext.Items).
Any thoughts on this issue?
That may be true. Making code perform thread safe may lead to some other side effects.
You may clone the CSLA code and make the required/proposed changes and test in your application. Then send a pull request of the changes to Rocky.
The trick will be to avoid the lock only in the case the code is running within an HttpContext.
I know for sure that when the code is running outside HttpContext and is using a static dictionary the lock is required. That is the case in most XAML-based runtimes.
Copyright (c) Marimer LLC