Bug 46900

Bug: 46900

Impact:

Informational

Product:

GemStone/S 64 Bit

Versions:

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.2, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.x, 3.1.0.6, 3.1.0.5, 3.1.x, 3.0.x

Platform:

All Platforms

Fixed In:

N/A

Persistent GsFile instances can lose transient state within same session

GsFile instances have always been transient objects that can only be used within a single session. If a GsFile was made persistent, attempts to reuse it in another session would trigger an error due to the loss of the transient state information about the file in use.

But due to a design change in GS/64 3.0, the behavior has changed to where in the *same* session, if a persistent GsFile is flushed from local memory due to GC activity and later faulted back in, it will also lose its transient state information and trigger the error:

   --------------------------
   a ImproperOperation occurred (error 2364), The object <aGsFile>
   that has some associated session state has lost that transient state.
   Examples of classes that use session state are GsSocket and GsFile.
   --------------------------

This behavior is also mentioned in the class comment for GsFile:

   --------------------------
   Beginning with Gs64 v3.0, instances of GsSocket automatically have
   their C state closed when the instance is garbage collected or
   when a persistent instance drops out of memory.
   --------------------------

Workaround

Make sure that GsFile instances do not become persistent.  This typically happens by having them referenced by other committed objects. Use of System>>sessionStateAt:[put:] is one way to access GsFile instances in a safe manner that will avoid having them become inadvertently committed/persistent.