Deploying a Space

In the previous section you have learned about data grid's capabilities as a data store. In this part of the tutorial we will show you how you can deploy an In Memory Data Grid (IMDGClosed In-Memory Data Grid. A set of Space instances, typically running within their respective processing unit instances. The space instances are connected to each other to form a space cluster. The relations between the spaces define the data grid topology. Also known as Enterprise Data Grid - EDG) that provides scalability and failover.

Data gridcan be used as a scalable application platform on which you can host your Java application, similar to JEE and web containers. However, GigaSpaces's IMDG can also be embedded within another Java application which is not hosted within the data grid platform. In this part of the tutorial we will show you how to start a data grid and how you can interact with it.

Getting Started

To start a data grid, run the following command:

This will start all the infrastructure required to run the data grid. The following components are started:

For more information, see the Service Grid Layer page in the Product Overview section.

When you execute the gs-agent command above without any arguments, 1 GSA, 1 GSM, 1 LUS and 2 GSCs will be started. The gs-agent command takes several different parameters as arguments.

For more information, see the Scripts page in the Administration guide.

Connecting to a Data Grid

In order to create a data grid, you need to first deploy it onto the GigaSpaces infrastructure. It's easy to write some code that connects to an existing data grid, or deploy a new one if the data grid does not exist. In the GigaSpace lingo, a data grid is called a SpaceClosed Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model., and a data grid node is called a Space Instance. The space is hosted within a Processing Unit (PUClosed This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity.), which is the GigaSpaces unit of deployment.

There are several ways you can deploy a new Data Grid; by command line, with java code embedded in your application and the admin UI. The following snippets shows how to deploy a data grid.

We want to deploy a data grid that has two primary partitions and one backup for each primary partition. Here are the gs and REST commands that you would execute to achieve this:

$GS_HOME\bin\gs.sh deploy-space  -cluster schema=partitioned total_members=2,1  xapTutorialSpace
curl -X POST --header 'Content-Type: application/json' --header 'Accept: text/plain' 

This command will start a space called xapTutorialSpace with two primary partitions and a backup for failover for each primary.

You can also deploy the space via Java code. Here is an example:

String spaceName = "xapTutorialSpace";

public void startDataGrid() {
    try {
        // create an admin instance to interact with the cluster
        Admin admin = new AdminFactory().createAdmin();

        // locate a grid service manager and deploy a partioned data grid
        // with 2 primaries and one backup for each primary
        GridServiceManager mgr = admin.getGridServiceManagers()

        ProcessingUnit pu = mgr.deploy(new SpaceDeployment(spaceName)
            .partitioned(2, 1));

    } catch (ProcessingUnitAlreadyDeployedException e) {
    // already deployed, do nothing

Lets take our online payment system. We are expecting thousands or even millions of payments to be processed over time and we want to store them in the IMDG. For this scenario we would like to partition our space into multiple partitions with each having a backup partition and the primary partitions are hosted on different machines then the backup partitions.

Here is how you would configure your IMDG: Lets assume we have 4 machines available. On all machines we will start a GSA. The default gs-agent script will give us a total number of 8 GSC's. We want to deploy 4 partitions each having a backup and there should only be one instance per machine.

$GS_HOME\bin\gs.sh deploy-space  -cluster schema=partitioned total_members=4,1 -max-instances-per-machine 1 xapTutorialSpace
curl -X POST --header 'Content-Type: application/json' --header 'Accept: text/plain' 

When the application write Payment objects into this space, data grid will use the routingClosed The mechanism that is in charge of routing the objects into and out of the corresponding partitions. The routing is based on a designated attribute inside the objects that are written to the Space, called the Routing Index. information provided (@SpaceRouting) by the Payment class to route the object to the right partition.

Interacting with the Data Grid

Now we are ready to interact with the data grid. All the examples we explored in the first part of the tutorial can be used to interact with the IMDG.

If you have started the IMDG within your application, you would acquire the space like this:

GigaSpace gigaSpace = pu.waitForSpace().getGigaSpace();

Here is an example how you can connect to the grid from your application:

// Create the Space
GigaSpace gigaSpace = new GigaSpaceConfigurer(new SpaceProxyConfigurer("xapTutorialSpace")).gigaSpace();

Web Management Console

You can start data grid's console and inspect the Data Grid components that have been started. In the data grid distribution you will find the command file to launch the console.


After you execute the above command, open a browser and go to http://your_host:8099 and the login screen for the admin application will open up. The following screen shots will demonstrate some of the UI features: (no username and password needed)

For more information, see the Web Management Console page in the Administration guide.