[Glass] reclaim before migrating

Otto Behrens otto at finworks.biz
Tue Oct 25 03:38:12 PDT 2022


Hi,

When we do migrations in our GemStone 3.6.5 databases, we sometimes do some
cleanup before we start migrating because we discovered some loose ends
before the release. This creates dead objects; then we have to ensure that
the dead objects are garbage collected because our migration process picks
up any object that can be migrated.

This process takes the system offline and we can then stop any "user" level
gems / topaz sessions. This helps to get migrations to run reliably through.

I am assuming the best way is to do a full markForCollection and reclaim
before we start listing objects that should be migrated. Is this a
reasonable approach?

We run SystemRepository reclaimAll after the markForCollection. We then try
to wait for all dead objects to be collected, but dead objects are still in
the repository. We use

SystemRepository findReferencePathToObject: (Object _objectForOop: xxx)

and then get

*** Scan completed *** (object is dead) Total time is 5 seconds

Is there a way to synchronously wait until the space used by dead objects
has been reclaimed? (and the object would not be picked up by
listInstances). This assumes that the only way to really know if an object
has been removed is if the space has been reclaimed. Or is there another
approach that will work?

Regards

Otto Behrens

+27 82 809 2375
[image: FINWorks]
[image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
www.finworks.biz

Disclaimer & Confidentiality Note: This email is intended solely for the
use of the individual or entity named above as it may contain information
that is confidential and privileged. If you are not the intended recipient,
be advised that any dissemination, distribution or copying of this email is
strictly prohibited. FINWorks cannot be held liable by any person other
than the addressee in respect of any opinions, conclusions, advice or other
information contained in this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20221025/6bf49b1b/attachment.htm>


More information about the Glass mailing list