1. GemStone/S 64 Bit 3.3.8 Release Notes

Platforms for Version 3.3.8

GemStone/S 64 Bit version 3.3.8 is supported on the following platforms:

• Solaris 10 and 11.3 on x86
• AIX 6.1, 7.1, and 7.2
• Red Hat Enterprise Linux Server 6.4, 6.9, 7.1, and 7.4;
  Ubuntu 14.04 and 16.04; and SUSE Linux Enterprise 12, all on x86
• OS X 10.11.2 (El Capitan) with Darwin 15.2.0 kernel, and OS X 10.13.2 (High Sierra) with Darwin 17.3.0 kernel, on x86 (Mac is supported for development only)

Supported Windows client platforms are

• Windows 7, Windows 2008 R2, Windows 8, and Windows 10

Note that (deprecated) Solaris/SPARC distributions are available for development and debugging only. Solaris on x86 continues to be fully supported.

For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.3.5 Installation Guide for that platform.

GemBuilder for Smalltalk (GBS) Versions

The following versions of GBS are certified with GemStone/S 64 Bit version 3.3.8:

Community and Web Edition licencing for GemBuilder for Smalltalk

The GemStone/S 64 Bit Community and Web Edition licensing now also include licencing for GemBuilder for Smalltalk (GBS). This allows free for commercial use, in production as well as development, for GBS.

The Community Edition license for GemBuilder applies to all GemBuilder client platforms, with Community Edition GemStone/S 64 Bit on Linux and Macintosh.

The Starter Community and Web Edition keyfile that is included in the GemStone/S 64 Bit distribution for Linux and Macintosh now allows GBS logins.

Added Support for AIX 7.2

This release adds support for AIX 7.2, which was verified on POWER7.

Updated library versions

The version of OpenSSL has been updated to 1.0.2p.

logsender and logreceiver stats for block ID

Currently, the logsender and logreceiver can record, in statmonitor data, the only the tranlog file being processed. Now the block ID is recorded in SessionStat00 in logsender, and SessionStat23 in logreceiver.

fullBackupTo: and restoreFromBackup: no longer limited to 16 sessions

The multi-threaded backup and restore are initiated with an upper limit on the number of slave sessions (threads). The actual number of threads may be further limited during the course of execution as the backup or restore respects the configured CPU and thread limits. These limits can be adjusted during runtime to further limit or increased the number of threads, but only up to the upper limit set when the operations initialized.

Previously, backup and restore set that maximum limit of the number of threads based on the number of extents, to a number between 2 and 16. With solid-state drives, however, backup and restore may no longer be I/O bound, and that limit of 16 can result in CPU-bound performance.

In this version, the maximum thread limit is still by default set, to two times the number of extents, but without the limit of 16. This upper limit can be further increased, before the backup or restore is started, by executing:

SessionTemps current at: #GsOverrideNumThreads put: numThreads

where numThreads is a value between 1 and 4 * the number of CPUs (inclusive).

Note that you should verify that your operation is CPU bound and not I/O bound before raising the threads maximum. Increasing the number of threads will not improve performance if the operation is limited by the performance of disk reads and writes.

The following private methods have been removed:

Repository >> _fullBackupTo:MBytes:compress:

Repository >> _restoreBackups:scavPercentFree:

Nested Transaction can create references to non existent objects

There is a sequence of processing within a nested transaction that has the ability to create a committed reference to an object that does not exist.

This involves a nested transaction followed by a failed commit of the outer transaction; then an abort and another commit. The problem is related to objects that were not correctly sorted between the closures of the inner and outer commits, such that state was not correctly handled by the abort. (#47659)

beginNestedTransaction did not handle instancesNonPersistent correctly

If the closure of a nestedBeginTransaction contained instances of classes with the option instancesNonPersistent, or other instances that were immune to rollback on abort, these objects were incorrectly being added to the closure of the nested transaction. This cause the later commit to the outer transaction to fail with error 2407, attempt to commit a not committable object. (#47584)

GCI Execute issues with UTF8 source containing code points over 255

GciExecute(), GciTsExecute(), and their variants did not work correctly with UTF8 source arguments that have code points greater than 255 (#47634)