I'm running into a StackOverflowException when making a call to SaveEntityCollection. I eventually tracked this down via WinDbg. It seems to be a recursive call of SD.LLBLGen.Pro.ORMSupportClasses.ObjectGraphUtils.ProduceAdjacencyLists.

Here's the WinDbg stack up till the line that starts repeating:

000000001C066AA0 000007FF006D19C0 SD_LLBLGen_Pro_ORMSupportClasses_NET20!SD.LLBLGen.Pro.ORMSupportClasses.CollectionCore`1[[System.__Canon, mscorlib]].InitCoreClass(Int32)+0xb0

000000001C066AF0 000007FF006D18C6 SD_LLBLGen_Pro_ORMSupportClasses_NET20!SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2`1[[System.__Canon, mscorlib]].InitClass(SD.LLBLGen.Pro.ORMSupportClasses.IEntityFactory2)+0x16

000000001C066B30 000007FF006D184F SD_LLBLGen_Pro_ORMSupportClasses_NET20!SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2`1[[System.__Canon, mscorlib]]..ctor(SD.LLBLGen.Pro.ORMSupportClasses.IEntityFactory2)+0x2f

000000001C066B70 000007FF006D17F3 EVE_DAL!EVE.DAL.HelperClasses.EntityCollection`1[[System.__Canon, mscorlib]]..ctor(SD.LLBLGen.Pro.ORMSupportClasses.IEntityFactory2)+0x33

000000001C066BA0 000007FF0102535D EVE_DAL!EVE.DAL.EntityClasses.ParcelObjectsEntity.get_LandSections()+0xad

000000001C066C10 000007FF018F74D8 EVE_DAL!EVE.DAL.EntityClasses.ParcelObjectsEntity.GetMemberEntityCollections()+0x1c8

000000001C066D50 000007FF00D146CF SD_LLBLGen_Pro_ORMSupportClasses_NET20!SD.LLBLGen.Pro.ORMSupportClasses.ObjectGraphUtils.ProduceAdjacencyLists(SD.LLBLGen.Pro.ORMSupportClasses.IEntity2, System.Collections.Generic.Dictionary`2<System.Guid,System.Collections.Generic.Dictionary`2<System.Guid,SD.LLBLGen.Pro.ORMSupportClasses.IEntity2>>, System.Collections.Generic.Dictionary`2<System.Guid,SD.LLBLGen.Pro.ORMSupportClasses.IEntity2>)+0x10f

What's interesting is that the problem only seems to happen if I have a larger amount of records to save. By larger, I think a worse case rough estimate is in the low 100s of thousands of entities to save. Another interesting thing that I see is the get_LandSections(). This should always be an empty collection. I'm not sure if that matters or not.

I realize we're using an old version of LLBL, but I didn't see anything in the newer version change logs. If possible, I'd like to keep using this version until we have the time to test our application with a newer build.

LLBL version 2.6. SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll is 2.6.12.1015 .NET 3.5, Adapter, SQL Server 2012

If you use fast serialization and you switched OFF (on by default) ObjectID inclusion, please switch that back on. Also you have to make sure you don't have cycles in the model (that's a warning in the designer).

it also could be (I think this is likely the cause) that the total graph is simply too big to save at once, as it uses recursion to traverse the graph. If the object graph is really big, the recursion could create a long stack (every recursion level creates a new stack frame) and therefore overflow. You should save things in a smaller set in that case, which means you should save things in batches using unit of work instances. I don't know whether this is doable in your application.

Walaa is spot on, it's the recursion which makes the stack too deep.

Walaa wrote:

If you use fast serialization and you switched OFF (on by default) ObjectID inclusion, please switch that back on. Also you have to make sure you don't have cycles in the model (that's a warning in the designer).

it also could be (I think this is likely the cause) that the total graph is simply too big to save at once, as it uses recursion to traverse the graph. If the object graph is really big, the recursion could create a long stack (every recursion level creates a new stack frame) and therefore overflow. You should save things in a smaller set in that case, which means you should save things in batches using unit of work instances. I don't know whether this is doable in your application.

I am saving in batches, but I guess my batch size is too big. I don't think we have changed any serialization options, so I doubt it's that. I have set my batch size smaller and it works. Thanks.

smaller batches is indeed the way to go if you have a massive amount of entities to save. The thing to realize with this is that 1 entity can reference (indirectly) all the other entities, so the graph traversal might run into the problem still, even though you save (recursively) just 1 entity.

Normally it's fine, only in extreme cases this is a problem.