Will LLBLGen 4.0 help (vs LLBLGen 3.x) for memory consumption?

Posts   
 
    
greenstone
User
Posts: 132
Joined: 20-Jun-2007
# Posted on: 04-Nov-2013 20:14:16   

Please disregard this posting. It should have really been a continuation of:

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=21601


Hi,

Finally back to this issue and trying to come up with a longer-term solution...

Will LLBLGen 4.0's enhanced memory footprint help with this this issue?

Otis said: _Entities which are part of a transaction are kept alive, because when the transaction rolls back, the values in the entities are rolled back as well. _

Might it be possible 4.0 has an option added/can be added, for a write-only situation like this (where we don't care about the state of the entities after the transaction), where the entity's memory is not held...so a large transaction can be performed?

kind regards,

Andy


greenstone wrote: Hi Daelmo,

Here's the basic structure of the complete code:

1.) De-serialize the XML into a hierarchical class (this does take a big chunk of memory that is be elevated...later on...into Gen 2 of the Managed Memory). The XML contains a long list of "Employee" objects (with associated array of child "Salary" objects)

2.) Create an adapter object

3.) Start a transaction on that adapter

4.) Loop through the Employee objects (and sub-loop through child Salary objects), fetch the LLBLGen Employee entity from the database (and Salary entties).

5.) Synchronize the Employee Entity with the (XML represented) Employee object (mapping fields based on a field-by-field synchronization mapping set of rules).

6.) Continue loop to the next Employee Entity.

-->When get through a few million entities, get the system-out-of-memory error.

From looking at the memory profiler, the only memory that is building up (when starting to loop through the Employee objects, and fetching the Employee Entities) are the LLBLGen generated Employee/(child)Salary Entities. The memory profiler seems to suggest these entities are not released for garbage collection until the .commit is done. The memory profiler also lists the transaction object as the root reference holder for these entities.

Correct. Entities which are part of a transaction are kept alive, because when the transaction rolls back, the values in the entities are rolled back as well.

Quote:

This is what I thought I had read on another/other LLBGen posts, and this would seem to explain the out-of-memory error. But I guess you're suggesting that the LLBGen adapter does not retain the memory of the Entity instances until the .commit is done?

It does.