This page describes an older version of the product. The latest stable version is 16.4.

Migrating from Hibernate

To benefit from data caching and other capabilities, it is worthwhile to migrate a legacy application that uses the Hibernate API, to the GigaSpace or GigaMap API. In such cases, these applications can benefit from the ability to scale when using the GigaSpaces Data Grid. This is achieved by partitioning the data across different spaces running on different machines, and having the business logic colocated with each partition. This allows the space and the business logic to run in same memory address, eliminating remote calls when accessing the data.

The following tables show the correspondence between the Hibernate basic API methods to GigaSpaces API and the GigaMap API methods.

org.hibernate.Session Method GigaSpace Method GigaMap Method
save write put
persist write put
delete clear remove
update write put
merge write put
saveOrUpdate write put
replicate write put
get read, readByID get
load read, readByID get
createSQLQuery readByIDs, readMultiple(SQLQuery) , Not supported

The Moving from Hibernate to Space best practice includes step by step instructions for moving from Hibernate based application to GigaSpaces Data-Grid as the data access layer. This use Hibernate as the space persistency layer using write-through approach when pushing updates into the database.

See also:

The space can be used as a Hibernate second level cache.

Caching policies and Space Persistency

Space Persistency supports the All In Cache and LRU Cache policies.

All In Cache Policy

With the All In Cache policy, the assumption is the Space holds the entire data in memory. In this case, the space communicated with the data source at startup, and loads all the data. If data within the space is updated/added/removed, the space is calling the SpaceSynchronizationEndpoint implementation to update the underlying data source. All data activities leveraging the data in memory.

LRU Cache Policy - Read-Ahead

LRU persistency model is based on the eviction model: Some of the data stored In-Memory (based on auto expiration mechanism or explicit data eviction) and ALL the data stored on disk where the preferred disk media is a database. You may leverage Hibernate as the mapping layer when data is persist or have a custom persistency mapping implemented leveraging the Space Data Source API.


GigaSpaces do not support the overflow model when persisting data since it may lead to inconsistency situations.

. Using a database to store the data allows you to:

  • Reload it very fast into the space with plenty of flexibility to customize the load activity.
  • Allows the system to query the database when needed.

Database technology has proven itself to be able to store vast amount of data very efficiently with very good high-availability. You may use RDBMS SQL databases (mySQL, Oracle, Sybase, DB2) or NoSQL databases (MongoDB , MarkLogic, AllegroGraph) as the space persistency layer.


When using NoSQL databases you may also leverage GigaSpaces Document API support to map complex data structure into a document data store model.

With the LRU policy, the assumption is that some of the data (recently used) is stored in memory. The amount of data stored in memory is limited by the cache size parameter, the memory usage watermark threshold parameters and available free GSC JVM heap size. In this case, once the space is started is loads data up 50% (you may tune this value) of the defined cache max size (total of objects per partition).

If data within the space is updated/added/removed, the space is calling the SpaceSynchronizationEndpoint implementation to update the underlying data source. When performing read operations for a single object (read/readById/readIfExists) and no matching object is found in-memory (cache miss), the SpaceDataSource implementation is called to search for a matching data to be loaded back into the space and from there sent to the client application (read-ahead). If a query is executed (readMultiple), and the max objects to read exceed beyond the amount of matching objects in memory, the SpaceDataSource is called to search for matching data elements to be loaded back into the space and from there sent to the client application. In this case, the client might have in return objects that were originally within the space, and objects that have been read from the data source and loaded into the space as a result of the query operation.


The IMDG with Large Backend Database Support best practice suggest a simple approach you may use to leverage LRU Space with a large database allowing the application to execute queries against the space in an optimal manner.

In both cases (ALL_IN_CACHE and LRU cache policy), you can customize the data load phase to speed up the space initialization phase.

Space Persistency

The space can load data from data sources, store data into data sources, and persist data into a relational data source or any other media via a custom SpaceSynchronizationEndpoint implementation. Space Persistency a built-in implementation using Hibernate, to store data in an existing data source and in the space. Data is loaded from the data source during space initialization (via the SpaceDataSource implementation), and from then onwards the application works with the space directly. Meanwhile, the data source is constantly updated with all the changes made in the space (via the SpaceSynchronizationEndpoint implementation). This is the recommended model.

The Hibernate Space Persistency support RDBMS. The Cassandra Space Persistency allows applications to leverage NoSQL Cassandra DB having a distributed database infrastructure as an alternative to RDBMS.