Overview

You may run the space as part of a separate remote stand-alone process (central), as part of your own application process (embedded), or as a combination of the central and embedded modes – master-local. In each case, the space can be transient or persistent, clustered or non-clustered.

Transient Space

Transient space is a pure in-memory configuration. All data in a transient space is stored in-memory and is not swapped to any persistent media (file, database).

Persistent Space

Persistent space stores its data both into memory and into a disk using an indexed file or a relational database. The amount of data stored in memory is limited where LRU eviction policy removes old entries from the memory.

For more details about Persistent space, see the Database Cache and Persistency section.

Central Space

The central space topology is in fact non-clustered. It imposes single point of failure architecture where all applications are using the same space instance.

A central space runs as part of a different process that does not share the same memory address space as the application, i.e., it runs as a separate process in the same machine where an application is running or on a different machine. Accessing a central space involves network calls and serialization/de-serialization of the cached objects between the client and the space process. This mode is used only in cases where the client application cannot run an embedded space (due to memory capacity limitations, etc.) or in cases where there are a large number of concurrent updates on the same object using different remote processes.

Embedded Space

A space is usually considered a network service that can be accessed by applications throughout the net.
Accessing a space over a network may have the following drawbacks:

• Reduced access speed – caused by the latency of the network.
• Service unavailability – caused by a network failure.
• Management overhead – caused by the fact that the space server should be started separately.
• Security issues – caused by the fact the space is exposed to attacks from other machines on the network.

Certain types of applications find it convenient to use a space, with all space semantics, as a local embedded entity running as part of an application's JVM. GigaSpaces supports this by allowing the application to receive a co-located proxy to a space, and to perform all space operations without requiring RPC calls. It is important to note that complete semantics of the JavaSpaces API, including transactions, leasing, persistency and remote events, are preserved by the embedded space.