Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Example: JDBC Hello World

This example shows how to connect to the space that runs on a local GigaSpaces server and manipulate data using the JDBC API.

This space is not a relational database: applications using the GigaSpaces JDBC interface are working with virtual tables. Each table is represented in the space by objects that hold its properties and data.

The JDBC interface should not be confused with the space persistency mechanism, which saves space data to an RDBMS or an indexed file.

In the persistency model, the database is transparent to the application: the application writes to the space using its native interface (which may be JavaSpaces, Map, JMS, or even JDBC) and the data is persisted to a database behind the scenes.

{color:red}How can one behind the scenes: (a) persist data into a database from this space? (b) load data from a database into this space?{color}

Where can I find an example?

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2110]{quote}

asked 2007-07-27 16:47:04 -0500

jeff_seattle gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted


The GigaSpaces JDBC API is not recommended to be used for space based applications that require sophisticated distributed workflow/parallel processing or distributed data-grid. It should be used for reporting and basic SQL query based applications.
We recommend the Open Spaces API that is based on Spring and JavaSpaces.

GigaSpaces persistent space includes several options:
1. out of the box persistency to RDBMS using classic fixed class to table mapping.
2. out of the box persistency to indexed file.
3. custom persistency having user defined implementation business logic
4. out of the box persistency using Hibernate - built on top of option 3
5. Async persistency via option 3 or option 4 - aka Mirror Service

The suggested way is to use option 5. This will make sure the database will not be in the critical path of the application. This would not affect the application performance in great deal as long as your database configured to cope with batch operations. This will make sure the database activity would not increase the rego log size within the space to store large amount of space events that will cause slow space performance (space send its activities in async mode to the database via the mirror).

Options 1-4 suggested for applications that can tolerate slow performance when performing destructive operations (write , update , take). In this case the persistency done in sync mode.
Option 2 support async file cache flush (swap schema) that can improve the performance but it would not be fast as option 5.
The main downside with options 3-4 is the need to build the business logic that will persist the data or create the Hibernate hbm files and make your classes to have relevant getters and setters (both for POJO and Entry classes).
In most cases the relevant business logic or the hbm files/getter,setters already exists so this issue becomes almost irrelevant.

In any case we suggest to use the persistent media (database) for recoverability and not to extent the space capability. This means the space should run using ALLINCACHE mode (relevant for options 1 and 2).
To increase the space capacity we suggest using the partitioned with backup space cluster schema.

Options 1 and 2 will pre-load the space cache once it is started by reading the data from the database/file. With large database , this might take some time.
With option 3 you may implement your own space data load using the ManagedDataSource.initialLoad method implementation.

\GigaSpacesEE6.0\examples\Advanced\DataGrid\Database-Integration\JdbcDataSource\src\com\jspaces\examples\datasource\jdbc\JdbcDataSource.java for an example.

Doc and Examples for the above options:
option 1 -

option 2 -

option 3 -

option 4 -

See as part of the readme:

option 5 -
See as part of the readme:


answered 2007-07-27 20:32:00 -0500

shay hassidim gravatar image
edit flag offensive delete link more


Thanks Shay

Initially, We would be more interested in reading from a database into a space, than writing to one; in other words, a WorldLoaderService.

We are creating this service which will not to be deployed by GigaSpaces.

We will run the WorldLoaderService once to setup the initial world to load a predefined set of objects and system properties from database into gigaspaces.

Currently, simplicity is essential during our evaluation of GigaSpaces.

jeff_seattle gravatar imagejeff_seattle ( 2007-07-29 14:48:03 -0500 )edit


Loading data into the space can be done in the following modes: - Remote loader mode - a separate application that explicitly executed when system starts before it is available for clients. When running partitioned space, data is partitioned based on the routing field hash code value into the relevant space. Batch operations and one way mode can push data into the cluster highly efficient manner. In this case you perform remote operations both when interacting with the space and the database.

  • Embedded loader mode - before the space is available for clients it perform initial load phase. This is the location where you can place your business logic that read the data from the database and load it into the space. In this case you avoid remote calls when interacting with the space since the data load done from within the space. You will need to perform remote calls when reading from the database.

When using the embedded loader - the ExternalDataSource interface should be implemented with its initialLoad() method to return an implementation of the com.gigaspaces.datasource.DataIterator that allows you to load into the space the relevant data set you want. When running partitioned space you need to load the specific data set the partition need to store. This means your database query needs to "slice" the correct data set from the database based on the partition ID. The partition ID can be retrieved from the ExternalDataSource.init(Properties) in the following manner:

{code} public void init(Properties prop) throws DataSourceException { int numberOfPartitions=((Integer)prop.get(ManagedDataSource.NUMBER_OF_PARTITIONS)).intValue();

   //load the data when the hashcode of the routing index MOD numberOfPartitions==partitionNumber-1
   int partitionNumber=((Integer)prop.get(ManagedDataSource.STATIC_PARTITION_NUMBER)).intValue();

} {code} The relevant database query should look like this: {code} Select * from Person where "MOD(PERSON_ID," + numberOfPartitions + ") = " + (partitionNumber -1) {code} Make sure the routing field (i.e. PERSON_ID) will be an Integer type.

See simple example at: \GigaSpacesXAP6.0\examples\Advanced\Data_Grid\Database-Integration\JdbcDataSource\


shay hassidim gravatar imageshay hassidim ( 2007-07-30 07:05:02 -0500 )edit

1. For Remote loader mode, is this separate application not deployed by gs-ui?

2. For Embedded loader mode, is this class (implemented with ExternalDataSource interface), deployed by gs-ui to each GigaSpace instance? Thereby, guaranteeing reading the data from the database and loading it into the space before the space is available for clients it perform initial load phase?

3. What is the following database query doing?:

Select * from Person where "MOD(PERSON_ID," + numberOfPartitions + ") = " + (partitionNumber -1)
jeff_seattle gravatar imagejeff_seattle ( 2007-07-30 13:17:05 -0500 )edit


Sorry for the late response.

  1. You can run remote application as stand alone application or as a PU that do not run collocated space. Simply have the space URL to be declared as the following (remote space access): {code}<os-core:space id="space" url="jini://*/*/mySpace"/>{code}

  2. You should deploy the ExternalDataSource implementation to each space. The ExternalDataSource.initialLoad() called before the space is available for client to access.

  3. This query should be called from the ExternalDataSource.initialLoad() implementation to retrieve the relevant database data set the space should load. The query involves the space partition ID and a table column that is used to retrieve the correct rows. Since each space partition stores a subset of the data , based on the entry routing field hash code value , you need to load the data from the database in the same manner the client load balance the data when interacting with the different partitions.

The calculation the database query is doing with the MOD , PERSON_ID , numberOfPartitions and the partitionNumber is identical to what a remote client is doing when performing write operations with partitioned space.


shay hassidim gravatar imageshay hassidim ( 2007-08-08 08:46:01 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2007-07-27 16:47:04 -0500

Seen: 381 times

Last updated: Jul 27 '07