G'day,
I've got a CSLA data loading application that generates a OutOfMemory Exception when I load 64,000+ children into a ChildList. I ran Red-gate memory profile 5.2 over the solution, and found some unexpected results when reviewing the memory usage. I found a series of CSLA based memory usage that didn't make sense to me. See screenshot below.
I can understand all the increases that match the volume of records in the child object, but the first few entries concern me. Does this indicate a memory leak in some of the CSLA namespaces?
Can anyone with Memory profiling experience shed some light on these results?
I ran into this problem recently. Here is my solution.
Upon construction, the Csla.Security.RoleForProperty class instantiates 6 List<string> objects for each of its properties. This happens even if you do not use Authorisation rules.
I changed the Csla.Secuirty.RoleForProperty and my memory leaks went away (and performance improved).
Here's what I changed:
You must change all the properties to lazy initialise the List<string> object.
Hope this works for you as it did for me.
That seems like a good optimization, I'll add that to the to-do list.
I don't know that a List<string> can be characterized as a memory leak though - just a waste if you don't use them 
Leak implies some reference scheme by which the memory can't be reclaimed - which typically comes from a static field or object maintaining a reference to non-static objects (either directly or by exposing a static event).
Hello,
We will be making this change in the CSLA 3.8.x branch. Here is a link to the bug.
Thanks
-Blake Niemyjski
Hello,
The fix has been checked in.
Thanks
-Blake Niemyjski
Copyright (c) Marimer LLC