GLASS/Seaside auto-migrate may error if Epoch enabled, or after MFC
In the GLASS/Seaside environment, operations that modify a Class definition and create a new version of the Class (including upgradeSeasideImage and code development), trigger an auto-migrate that migrate existing instances of that Class to the new version. The auto-migrate invokes a repository scan operation, to detect instances that need migration.
However, if the garbage collection steps of voting or atomic promote occur during this auto-migrate scan, the scan operation will fail (see bug 49651) with the error "Voting occurred or an atomic promote detected during the operation, results are compromised- please try again".
The voting step occurs after a markForCollection or epoch garbage collection. While markForCollection is invoked manually, epoch garbage collection (which is disabled by default), may start at any arbitrary time, based on the configured interval and number of transactions; and the actual voting/atomic promote that triggers the error in auto-migrate occurs some interval after the MFC/epoch starts.
Note that in GemStone 3.6.1 and earlier, the scan returned an empty collection and did not error; the instances were not migrated. Depending on the circumstances, this may or may not cause issues. Auto-migration migrates any class with a class history, so any unmigrated instances would be migrated during the next class definition change operation.
Workaround
To be safe, disable epoch during the upgradeSeasideImage steps of upgrade, and when doing code updates that create class shape changes.
Also, consider the timing when starting a markForCollection, and be aware of any automated markForCollections; be sure that the subsequent voting has completed before starting upgrade or performing code updates that create class shape changes.
For more information, contact the GLASS list (http://lists.gemtalksystems.com/mailman/listinfo/glass), or contact GemTalk Technical Support.
Last updated: 9/8/22