[Glass] Debug why objects get committed

Dale Henrichs dale.henrichs at gemtalksystems.com
Tue Mar 30 10:17:30 PDT 2021


Could you tell me the classes of the objects that you are concerned about and/or the code that is executed that creates these objects? I would like to read the code and see if I can figure something out ... it's been quite a while since I've been in that code, so giving me a pointer to the suspicious code (and a SHA or mcz of the code you are using) I can parachute in and start poking around ...
On Mar 30 2021, at 10:00 am, Johan Brichau via Glass <glass at lists.gemtalksystems.com> wrote:
> 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
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20210330/5717ec1f/attachment.htm>

More information about the Glass mailing list