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

[Dale Henrichs]

Paul,

Re-running the migration is one piece of the puzzle (GsDeployer class >>
cleanClassHistory will migrate any classes that have not been migrated).

The other piece of the puzzle is the consequences of an unexpected error
during code load into a production system.

My operating assumption is that developers test their load process on a
"copy of production" prior to running code updates on a production system
to flush out any errors that may show up during the process. However,
because this error is not predictable, a test on a copy of production may
not reveal that there is an exposure to this error, unless you ensure that
no voting can occur while loading code into production.

As I think about this more, You CAN guarantee that the only consequence of
this error is to "re-run the migrate" by using  GsDeployer
class>>bulkMigrate:, because the list instances phase is deferred until the
block is finished executing and a commit is performed immediately prior to
the list instances call ...

Dale

On Mon, Sep 12, 2022 at 8:45 AM PAUL DEBRUICKER via Glass <
glass at lists.gemtalksystems.com> wrote:

> 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
>
> _______________________________________________
> 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/20220912/8d5a9862/attachment.htm>