Hi all
We just ran into a very nasty problem in production where a statically shared CSLA ReadOnlyBase object (used for caching static information to reduce DB hits) caused the Application Service hosting the WCF data portal to max out the CPU's at 100%.
After catching the issue happening again, doing a memory dump and some adventures in WinDbg + SOS,
tracked it down to all the threads sitting at the top of the following stack:
System.Collections.Generic.Dictionary`2[[System.__Canon, mscorlib],[System.Boolean, mscorlib]].FindEntry(System.__Canon)
Csla.ReadOnlyBase`1[[System.__Canon, mscorlib]].CanReadProperty(System.String)
Csla.ReadOnlyBase`1[[System.__Canon, mscorlib]].GetProperty[[System.Int32, mscorlib]](Csla.PropertyInfo`1<Int32>, Csla.Security.NoAccessBehavior)
The ReadProperty method actually seems to cope, but it's the lookup of the property in the Field Manager Dictionary where it goes pear shaped.
As a workaround, we're instead caching the individual valuetype values instead of the object and creating clones for reference types.
Just wanted to know what the expectation of multi-threaded access to a CSLA business object's properties are from a design point of view.