[Glass] Debug why objects get committed

[Johan Brichau]

Hi,

I’m busy investigating why a bunch of objects get committed to the database but I’m having some trouble finding the right tools and method to investigate that.

The task that creates the objects is ran inside (a previous version of) the ServiceVM framework [1].
This task creates a lot of temporary objects and commits the result at the end. 
For some reason, these intermediate temporary objects are committed to the database and since it’s quite a large number of intermediate objects this occurs in steps of 100M per task (which is also the temp obj space for the topaz running the task).

I’m trying to find the reason the objects are committed but fail to do so.
When, from a different topaz session, I ask any of those objects ’SystemRepository findReferencePathToObject: theObject’, I’m always getting a false result and when running the MFC, the objects are indeed gc’ed.

But I want to prevent to commit that garbage.

The only reason I can think of is that the link of those objects to the persistent root was through the block that was scheduled in the ServiceVM framework. Since that block is removed once the tasks has finished executing, there is no persistent path anymore to the intermediate objects and persistent root, which would confirm why I cannot find any.

Right now, I’m just poking at the code and trying to find and break the link from the persistent root to the intermediate objects before the task commits.
Are there better ways to start investigating this? Usually, when the database grows I can find the problem via #findReferencePathToObject: but now, the committed objects are already garbage when I get to them…

Any hints appreciated ;-)

cheers
Johan


[1] https://github.com/GsDevKit/ServiceVM