Overview

The space is the main component of GigaSpaces. It is a distributed shared memory unit, which stores data and can perform four basic operations: write, read, take, and notify. The space runs in a Space Container (see below). Each space has an XML configuration file – a schema – that controls its behavior. Several predefined schemas are provided with GigaSpaces. A space configuration can be loaded as a resource, and should be part of the classpath of the JVM running the space. You can configure the space by editing the schema, or using the GigaSpaces Browser.

To learn about space persistency configuration, please see Database Cache and Persistency.

Implicit & Explicit Indexing

In JavaSpaces, reading is based on template matching: an application writes a template, and the space searches sequentially for entries that match it. To improve performance, the space can maintain an index of class properties. This speeds read operations, but also consumes server resources, so you should only index fields commonly used for matching.

If you want the space to automatically index the first n fields of each class, use the <number-implicit-indexes> tag in the space schema. This is called implicit indexing.

To index certain fields of a specific class, implement as part of the entry class the method public static String[] __getSpaceIndexedFields(). This is called explicit indexing.

Clustering Options

The space schema includes the <config-url> tag, which specifies the location of the cluster schema used to cluster the space. Each space could have one cluster schema.

The cluster schema should be accessible to all cluster space members. You can copy the schema to the local directory of each space server, but the drawback is that you have to distribute it yourself. You can put it in a shared network directory, or on a web server, but then you must ensure that this location is available at runtime to every machine running a space in the cluster.

Concurrency Control

GigaSpaces is based on the concept of a working group, which consists of a pool of worker threads and a thread-safe request queue. The worker threads listens to requests on the queue, and each request is handled by one thread.

The thread pool itself is dynamic, in the sense that threads can be created dynamically when the system load increases (which increases the level of concurrency), and threads can be destroyed dynamically when system load decreases (which frees system resources).

The GigaSpaces engine distinguishes between three types of requests:

• Immediate requests – write, take and read without timeout. These are processed immediately using the user's thread.

• Time-based requests – take and read with timeout, and notification sequence generation. These are processed using a dedicated working group.

• Notifications requests – dispatching events to registered clients. These are processed using a dedicated working group.

Space Filters

Filters are interceptors inside the GigaSpaces space engine that enable integration with external systems and implementation of user-defined logic based on space events. With concurrent access to the space, all clients share the same filter instance object where the space engine access the same filter object on behalf of each client. Every non-thread-safe attribute used as part of the filter implementation must be thread-safe protected.

Filters should not use 'heavy' business logic, because this can have a performance penalty.

Space Workers

Space workers allow you to run business logic in the space JVM. Workers are typically used for monitoring, to perform calculation-intensive operations, etc.

The space starts the worker business logic when started, and stops it when shut down. As opposed to space filters and the replications filters, the space does not call the worker implementation when a space operation is called. The worker can register for notifications, call take or read operations, or perform any other space operation. The worker accesses the space in embedded mode – there are no remote calls between worker and space.

The worker consumes memory from the same JVM the space is running.

The Space Container

The space container is a logical unit of the GigaSpaces server. Every space runs in a space container; more than one space can run in a single container. The container maintains a detailed list of the spaces running in it, registers its spaces into the Jini Lookup Service, and maintains the leases it receives. It listens to new lookup services that enter the environment and ensures that its spaces are registered to these lookup services.

Every GigaSpaces container is configured using an XML configuration file - the Container Schema.

Section Contents

• Cluster Configuration URL - Space Schema — Setting location of cluster configuration using the <cluster> tag of the space schema.
• Communication Protocol - Space Schema — Setting communication protocol, ports, connections, threads and retries.
• Concurrency - Space Schema — This section describes how to configure the different thread pools GigaSpaces utilize.
• Container Schema — Configuration options in the container schema, including security, port, directory services, JNDI, Jini Lookup, JMS, and logging.
  • Logging for GigaSpaces 5.0 — The logging system used with GigaSpaces 5.0 - a description of the system, how to set the log message format and the logging level.
• Controlling Serialization — Controlling the Entry attributes serialization mode when written/read from the space.
• Dirty Read - Space Schema — Defining whether objects under a transaction should be visible to read operations.
• Forced Rollback - Space Schema — Forcing a release of all locked transactions, when restarting a persistent space.
• Indexing - Space Schema — Setting implicit indexing, extended indexing, and related options.
• Lease Manager — The space includes a dedicated thread that is responsible for clearing expired Entries.
• Memory Management - Space Schema — Setting cache policy, memory usage and rules for exceeding physical memory capacity.
• Schema Evolution — The space schema can be evolved by using codebase downloading and Java extentions, or the explicit data migration process.
• Schema Name - Space Schema — Setting schema name using the <schema> tag of the space schema.
• Service UI - Space Schema — Setting class name and URL for the space service UI.
• Slow Consumer — The space includes a special mechanism that detects clients that cannot consume the notifications sent fast enough – i.e. slow consumers.
• Space Configuration Search Path — When a space loads, the container searches for its configuration in the rooot folder, in the JAR, and if absent, loads default configuration.
• Space Filter - Space Schema — Defining which space filters should be active and how they should operate.
• Space Worker - Space Schema — Setting worker names, implementation classes and arguments.
• Specifying Container Name and Settings — How to specify the container name when starting a space; overwriting default container configuration in runtime.
• Starting Multiple Spaces in One Container — Creating spaces by adding tags to a container's schema file.
• Starting Space with Container — Starting a space container with a single space using the CLI commands gsServer or gsInstance.