I am iterating through 2000 business objects using CSLA 3.8.1.
I instantiate them one at a time, call a processing function, and then advance the loop.
The memory usage just keeps incrementing.
When I run ANTS memory profiler, it gives me this:
ObjUser(this as BusinessBase)._childChangedHandlers
System.EventHandler<Core.ChildChangedEventArgs> (this as MultiCastDelegate)._invocationList
System.Object[]
System.EventHandler<Core.ChildChangedEventArgs> (this as Delegate)._target
ObjUserDetail(this as BusinessBase)._fieldmanager
These objects have not subscribed to the ChildChanged event.
Can anyone shed some light on what I should be looking for to eliminate these event handlers from preventing garbage collection?
First, you should check the change logs for 3.8.2, 3.8.3 and 3.8.4 to see if there've been any bug fixes around parent-child relationship management over that time.
Second, you should realize that within an object graph the objects handle each other's events. In particular, a parent always handles events from its children. But that doesn't matter from a memory perspective, since that is all contained within the object graph.
What isn't clear to me from your post is whether something outside the object graph is somehow handling the events?
Third, and this is perhaps the issue, you can only use a managed backing field to reference a child object. People sometimes use a managed backing field to implement a "using" relationship - to hold a reference to a non-child object. That's bad. That'll cause all sorts of issues - including n-level undo confusion, serialization nastiness and quite possibly memory leaks due to event handlers.
But if that's the issue, that's just a bug in the business code.
We put a business object (User) in the Custom Identity and were assigning it to each object's "User" property before we wrote it to the database.
That reference (User-->CustomIdentity-->CustomPrincipal) was preventing the object from being garbage collected.
Thanks for the direction Rocky. There is nothing more frustrating than a memory leak.
I'm glad you found the issue. Memory leaks really are frustrating...
Copyright (c) Marimer LLC