[Glass] reclaim before migrating

Otto Behrens otto at finworks.biz
Thu Oct 27 10:07:10 PDT 2022

Thanks, Dale. I sort of got something going. Still mysterious sometimes  :-)

On Thu, 27 Oct 2022, 18:26 Dale Henrichs, <dale.henrichs at gemtalksystems.com>

> Otto,
> I was hoping that someone else would be able to answer your question,
> since I don't know the answer off the top of my head :) Sooo, I think that
> this would be a good question for an HR ...
> Dale
> On Tue, Oct 25, 2022 at 3:39 AM Otto Behrens via Glass <
> glass at lists.gemtalksystems.com> wrote:
>> 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.
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20221027/a529c70f/attachment.htm>

More information about the Glass mailing list