Bug 40503

Bug: 40503

Impact:

Critical

Product:

GemStone/S 64 Bit

Versions:

3.1.0.6, 3.1.0.5, 3.1.0.4, 3.1.0.3, 3.1.0.2, 3.1.0.1, 3.1, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.6, 2.4.4.5, 2.4.4.4, 2.4.4.3, 2.4.4, 2.4.3, 2.4.2, 2.4.1, 2.4, 2.3.1.6, 2.3.1, 2.3, 2.2.6.5, 2.2.5.4, 2.2.5.3, 2.2.5.2, 2.2.5.1, 2.2.5, 2.2.4, 2.2.3, 2.2.2, 2.2.1, 2.2

Platform:

Fixed In:

n/a

Risk in modifying GsCurrentSession>>initialize

The method GsCurrentSession>>initialize provides a way for you to add application
specific behavior for every login to the repository in version 2.x and
3.0.x.

However, unhandled errors in the application-specific modifications may
cause session initializaion to be incorrect for all subsequent logins to
the repository. This incorrect initialization may allow login, but disable
all commits for this session. This is not recoverable; you must restore
from backup taken before the modifications were committed.

In version 3.1, loginHook: has been added to UserProfile instances allowing
you to more safely attach login behavior.  In version 3.1 and later, you
should not modify GsCurrentSession>>initialize.

Workaround

There is no workaround, you must restore from backup to recover.  If this
is not possible for critical applications, contact GemStone Technical Support.

Make a backup of the repository prior to making any modifications to this
method.

Leaving a separate idle session logged in as SystemUser, while modifications
are being tested, will allow these modifications to be removed to recover
the system.

Only executing the modifications for users other than SystemUser, and handling
errors in the modifications, will also help avoid situations requiring
restore from backup. For example,

(self userProfile userId = 'SystemUser') ifFalse: [
  [user code]
    on: (Globals at: #Error)
    do: [:ex | ex return]
   ].