[Glass] reclaim before migrating

[Dale Henrichs]

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/6ee64bc9/attachment.htm>