ChildUpdate parameters may cause Excessive memory usage (OutOfMemoryException)

[GoogleCodeExporter]

What steps will reproduce the problem?
1.CodeSmith: v5.2.2, CSLA Templates: v2.0.1.1681, CSLA Framework: v3.8.2
2. Created as parent + child list
3. Added 64,000 records to the child list.
4. Tried to save the record.
5. Recieved an OutofMemoryException.

What is the expected output? What do you see instead?
1. Do not pass down the parent (I don't think it's needed + if you have a large 
number of child items then it could cause a memory leak!)

ER - Modify DataPortal_Insert/Update with the following.
Current:      FieldManager.UpdateChildren(Parent, connection)
Recommended:  FieldManager.UpdateChildren(identifier, connection)

ECL - Modify the Child Item update statement as folows
Current:      DataPortal.UpdateChild(item, list.Values.ToArray())
Recommended:  DataPortal.UpdateChild(item, parameters) ' You can drop the list 
manipuation code you were doing in the same process.

EC - Modify Child_Insert/Update with the following.
Current:      Private Sub Child_Insert(ByVal parent As Parent, ByVal connection 
As SqlConnection)
Recommended:  Private Sub Child_Insert(ByVal ParentID As Int32, ByVal 
connection As SqlConnection)

Hope this makes sense.  I did a very large memory profiling test on this change 
and it reduces memory consumption significantly.  +1024 MB down to 607MB. There 
is still an issue after this logic change, but this helps reduce the codesmith 
templates contribution to the memory usage.  Looks like the TransactionScope 
trying to save large volumes of records at the same time triggers the out of 
memory error now (much later in the process after this change).

Original issue reported on code.google.com by JenasysD...@gmail.com on 9 Jun 2010 at 5:44

[GoogleCodeExporter]

Here is an image comparing the memory usage.
I've also cross posted an issue with CSLA role in the memory usage. Looks like 
CSLA Security consumes a lot of memory. See 
http://forums.lhotka.net/forums/p/9053/43030.aspx#43030

Original comment by JenasysD...@gmail.com on 9 Jun 2010 at 11:32

Attachments:

• Issue934_LargeMemoryUsage.png

[GoogleCodeExporter]

The memory optimisation suggested to the CSLA framework on the CSLA forum seems 
to have reclaimed some of the Memory usage (100MB) which might just be enough 
of a tipping point for my application and this volume of data.

Original comment by JenasysD...@gmail.com on 9 Jun 2010 at 9:46

[GoogleCodeExporter]

Nope, still get an exception during the "TransactionScope" saving of this CSLA 
data with 64,000 records. Looks like the high volume of memory used by the 
underlying CSLA framework is leaving limited space for the Transactions memory 
requirements.

3MB Excel file become 54MB in memory via a .net Dataset then becomes 600+MB via 
CSLA ER + ChildCollection containing 64,000 rows, then just blows up during the 
transaction.

Original comment by JenasysD...@gmail.com on 10 Jun 2010 at 11:35

[GoogleCodeExporter]

Hello,

Did you see if passing the connections by ref made any difference?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 10 Jun 2010 at 2:47

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Critical, Framework-CSLA

[GoogleCodeExporter]

Tried ByRef but that fails. I'm sure it's to do with the serialization side of 
things during this process.  
It's also interesting the way FieldManager manager matches the number of 
parameters, but doesn't match the TypeOf parameters, so you can pass items that 
are not the same type (ARH). This caught me a few times.

Original comment by JenasysD...@gmail.com on 10 Jun 2010 at 10:02

[GoogleCodeExporter]

Original comment by bniemyjski on 15 Jul 2010 at 3:48

• Added labels: Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

Original comment by bniemyjski on 9 Mar 2012 at 1:13

• Removed labels: Priority-High