Skip to main content

Platform Overview

GemStone/S 64 Bit is a distributed, multi-user, transactional object database. This article explains what it is, how its processes fit together, and where it fits compared to a relational database.

What is GemStone/S?​

GemStone/S 64 Bit is a server-based object database that runs GemStone Smalltalk as its query and application language. It stores objects directly to disk without translation, so you don't manage tables or an object-relational mapping (ORM) layer, or write SQL. The platform supports thousands of concurrent users, repositories with billions of objects, and sustained transaction rates of hundreds of transactions per second.

GemStone has powered mission-critical deployments in financial services, government, healthcare, utilities, and telecommunications since 1982. GemTalk Systems has maintained it continuously since that time.

When GemStone fits: GemStone works well for applications with deeply nested or highly interconnected data structures, where the cost of translating objects to and from relational tables creates performance or complexity problems. It also works well for workloads where business logic runs close to the data, inside the server or in GemStone Smalltalk, not in a separate application tier.

How GemStone differs from a relational database​

GemStone/SRelational (SQL)
Storage unitObjects with class hierarchyTables and rows
Query languageGemStone Smalltalk predicatesSQL
Schema changesClass versioning + instance migrationALTER TABLE
RelationshipsDirect object references (OOPs)Foreign keys and JOINs
ConcurrencyOptimistic and pessimistic; per-object locks; reduced-conflict collection classesRow/table locks, MVCC
ScaleBillions of objects, bounded by diskBounded by table and index size
Application logicRuns as Smalltalk methods inside the serverRuns in a separate application tier

The most significant architectural difference is that GemStone eliminates the object-relational impedance mismatch entirely. The application models data in whatever structure it requires, including hierarchies, networks, queues, and nested collections. GemStone does not assemble data objects at query time.

Process architecture​

A running GemStone system is made up of several cooperating processes. Understanding them helps with installation, configuration, and troubleshooting.

Stone​

The Stone is the central resource coordinator. One Stone process manages one repository. It synchronizes commit activity, resolves transaction conflicts, and is the single communication point for all Gem sessions. The Stone also coordinates with the Shared Cache Monitor to manage memory allocation across active sessions.

Gem​

Every user session runs inside a Gem process. The Gem executes GemStone Smalltalk, maintains the session's private snapshot view of the repository, and pages objects in and out of the Shared Page Cache as needed. A running system has both user Gems, one per active login, and one for system maintenance Gems. Maintenance Gems include GcGems, which handle garbage collection of unreferenced objects, and the SymbolGem, which manages the creation of unique canonical symbols. User Gems can be distributed across multiple servers; they do not need to run on the same host as the Stone.

NetLDI​

The NetLDI (Network Long Distance Information) process is the network broker that starts Gem processes on demand and coordinates startup when GemStone processes are needed on a different host than the one the Stone is running on. Most multi-host configurations require at least one NetLDI per server node.

Shared Page Cache​

The Shared Page Cache (SPC) is a large area of shared memory used by the Stone and all Gem processes on the same host. It is the primary performance lever in GemStone: frequently accessed objects stay in cache rather than re-reading from disk, and the Shared Cache Monitor prevents large queries from flushing working data out of memory. Cache size is configurable and has a direct impact on throughput for read-heavy workloads.

Extents and the repository​

The repository is the logical storage unit, the GemStone equivalent of a database. Physically, a repository is stored as an ordered collection of one or more extents, which are standard disk files or raw disk partitions. Repository size is bounded by disk capacity, not available RAM. A repository can contain billions of objects, each with a unique object-oriented pointer (OOP).

Transaction log​

The transaction log provides point-in-time roll-forward recovery. At commit time, only log records are written. Object pages remain in the cache for reuse, which keeps commit I/O low. Transaction logs can be written to file systems or raw devices.

How object persistence works​

GemStone uses the Smalltalk object model. Like a single-user Smalltalk image, it consists of classes, methods, instances, and meta-objects. All persistent objects in the repository descend from a named root called AllUsers.

You establish persistence by attaching a new object to an already-persistent object and committing the transaction. Until that commit, the object exists only in the session's private memory and other users cannot see it. After the commit, the object becomes part of the shared repository and users in authorized sessions can see it.

This is different from a relational database, where an INSERT immediately targets shared, durable storage. In GemStone, you work with objects freely in session memory, attach them to the persistent graph when they are ready, and commit when the transaction is complete. Objects that never attach to the persistent graph are temporary; GemStone discards them when the session ends.

A single user may have multiple simultaneous sessions open, and each session maintains its own consistent snapshot view of the repository. Changes from other sessions become visible after the next transaction boundary.

Client interfaces​

GemStone applications can access objects and execute methods from several languages. The primary interfaces are:

  • GemStone Smalltalk / Topaz — the native command-line interface for repository operations, scripting, and development. GemTalk includes Topaz with the server distribution..
  • GemBuilder for C — a library of C functions that provides a bridge between C application code and the GemStone repository. GemTalk includes GemBuilder for C with the server distribution.
  • GemBuilder for Smalltalk — connects a client Smalltalk image (VisualWorks or VA Smalltalk) to a GemStone server. Distributed as a separate product.
  • GemBuilder for Java — a Java runtime package providing a message-forwarding interface between a Java client and a GemStone server. Distributed as a separate product.
  • GsDevKit — an open-source development kit providing a Pharo-compatible GemStone Smalltalk environment, available via GitHub.