Bug 49382

Bug: 49382

Impact:

Critical

Product:

GemStone/S 64 Bit

Versions:

3.6, 3.5.5, 3.5.4, 3.5.3, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4

Platform:

Fixed In:

3.6.1, 3.5.6

Nested transactions that modify kinds of IdentityBag have risk of undetected corruption in tranlogged data

When collections are modified in GemStone, only the changes are logged to the transaction logs; this incremental logging avoids transaction log bloat.  In the case of modifications to certain kinds of collections (subclasses of IdentityBag), when the modification is done within a nested transaction, the incremental logging was not correct.

If these tranlogs were replayed, either after restore from backup, or in a warm or hot standby system, the restored collection may contain nils rather than valid results. Object audit did not detect this, since the elements were nil.

This bug only occurs when the modifications are from within nested transactions, e.g., after invoking beginNestedTransaction; and only for modifications to instances of subclasses of IdentityBag. The affected collections are:

IdentityBag
  BucketValueBag
  IdentitySet
    AbstractUserProfileSet
      UserProfileSet
    ClassSet
    GsObjectSecurityPolicySet
    RcIdentitySet
    StringPairSet
    SymbolSet
    UserProfileGroup ( groupName)
  RcIdentityBag ( components)
  RcLowMaintenanceIdentityBag

Workaround

Upgrade to a version with the fix; due to related bugs, you should upgrade to v3.6.2 or later, or v3.5.8 or later.

Contact GemTalk Technical Support for a limited distribution 3.4.x release providing a workaround.