[Glass] reclaim before migrating

[Otto Behrens]

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>
wrote:

> 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>