[Glass] Auto-migrate has risks with epoch garbage collection enabled

PAUL DEBRUICKER pdebruic at gmail.com
Mon Sep 12 08:30:27 PDT 2022

Hi sorry- Is the error display, needing to re-run the migrate after the partly-finished-mfc, and classes with partially migrated instances in the stone during that time the only consequences of this?  

> On Sep 8, 2022, at 4:51 PM, Lisa Almarode via Glass <glass at lists.gemtalksystems.com> wrote:
> GemStone v3.6.2 and later contain a bug fix that causes errors in auto-migrate in the GLASS/Seaside environment
> GLASS/Seaside provides auto-migrate when code is filed in that modifies class definitions; this requires a repository scan, that cannot complete if voting occurs while it is running. Epoch garbage collection, if enabled (it is disabled by default), means that voting could occur triggered by background operations. The change in v3.6.2 was to make the repository scan failure explicitly report an error, rather than silently returning an empty collection.
> This all means that if epoch is enabled, and then classes are modified in the GLASS/Seaside environment, it could report the alarming error "Voting occurred or an atomic promote detected during the operation, results are compromised- please try again".
> To be completely safe, we recommend disabling epoch in GemStone while performing code modifications that modify class definitions, or during upgradeSeasideImage.  You should also be aware of when markForCollection runs (either manually or by any automation you have written), and ensure that voting is complete before starting upgrade or making code changes.
> The GemStone server fix:
> https://gemtalksystems.com/data/bugnotes/49651.html
> The automigrate issue:
> https://gemtalksystems.com/data/bugnotes/50078.html
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass

More information about the Glass mailing list