If abort updates over more than GEM_ABORT_MAX_CRS commit records, GBS traversals may not include updates to persistent objects
On abort, a Gem must move its commit record view from the view acquired on the previous commit or abort, to the latest commit record.
The configuration parameter GEM_ABORT_MAX_CRS allows you to limit the number of commit records that are analyzed on Gem abort; if the number of commit records that must be crossed is larger than this, objects are all invalidated and must be re-read.
However, of the number of commit records that must be crossed is higher than this limit, the subsequent traversal result seen by GBS may not include all of the exported objects.
This means that if there are unmodified committed objects that are replicated to GBS, and these objects have been changed by other sessions, these changes are not visible in the Gem's view after the abort.
Note that this bug only applies when the commit record backlog exceeds the Gem's setting for GEM_ABORT_MAX_CRS. In earlier versions of GemStone, the default was unlimited; in v.3.5.1 and later, the default is 100000 for local sessions and 33333 for remote sessions.
Workaround
If your application sees large commit record backlogs, set GEM_ABORT_MAX_CRS to the maximum, 2147483647.
While the documentations states that a setting of 0 means no limit; this is not correct in some product versions. See
bug 49448
Last updated: 7/10/24