The space can load data from external data sources, store data into external data sources, and persist data into a relational database or an indexed file.
A space can interact with an external data source, such as a database, in order to extend or back up the physical memory of the process running the space. When searching for desired objects, the space uses both its process memory (cache), and its persistent media files. When the space is restarted, data from the media files can be loaded into the space cache.
The space can also be used as a Hibernate or JDO second level cache.
GigaSpaces provides several persistency models, which allow different modes of interaction with a database.
All external data source space interaction is based on one common interface – the IStorageAdapter. The Storage Adapter (SA) is the GigaSpaces engine component responsible for loading data from external resources, storing data into external resources, and persisting data to durable storage when performing space operations.
In addition to the IStorageAdapter, GigaSpaces exposes several interfaces and persistency implementations. Each provides a different persistency model suitable for a different scenario. These persistency models are described below.
JDBC Storage Adapter
Persists space operation into RDBMS. Mapping is done using the classic class-to-table approach. Data in the database is owned by GigaSpaces and may not be modified by external applications; it can be accessed directly via database interfaces in read-only mode. The JDBC SA option supports any RDBMS and using the JDBC driver to interact with the database.
This option supports implicit data recovery from the database when a space is started, stores Entry meta data and notify templates, and persists a redo log, providing reliable asynchronous replication.
CacheLoader & CacheStore
When an object is written to the space, the CacheStore implementation is used to update the external data source with space destructive operations (write, update and take). This method is used to store the object's content in the database table. When an application attempts to read data from the space, and it does not exist within the space, the CacheLoader or CacheIteratorFactory implementation is called.
These interfaces can retrieve data, based on passed template or key, from the external data source back into the space, and return it to the client as a space Entry. The CacheBulk implementation is used when performing a space operation with a transaction. The CacheBulk implementation allows the space to perform all of the specific transaction operations in one database transaction, ensuring that the space's data is coherent and consistent with the database's data, and vice versa.
This option does not support:
Implicit data recovery from the database when the space is started.
Storing of Entry meta data and notify templates into an external data source.
Persisting redo log data when performing a replication.
The CacheLoader, CacheIteratorFactory, CacheStore, and CacheBulk interfaces are supported both by the JavaSpaces API and by the Map API.
Hibernate CacheLoader & CacheStore
Enables mapping of space objects to database tables using Hibernate configuration files. In this case, the Entry class should implement getter and setter methods for the relevant fields. You may also use POJO classes and have the space class mapping, using annotations or gs.xml space mapping configuration files. gs.xml configuration files can be generated via Hibernate mapping files to speed up the mapping process.
The space is accessed via the Hibernate API. Hibernate query results and data are saved in the space. Repeated query results are fetched from the space, not from the database.
This option mostly boosts database read operations.
A reliable asynchronous persistency – enables space operations to be delegated in a reliable asynchronous manner into a dedicated service that interacts with the database or external data sources in batch mode for maximum efficiency. In this case, the CacheBulk implementation is also used to perform the asynchronous delivered operations against the external data source in one batch. GigaSpaces provides default implementation of the CacheBulk implementation used by the Mirror Service, to persist objects into RDBMS using Hibernate mapping files.
An indexed file holds the space data in memory for small durations and periodically flushes data into a file. With this option, the interaction with the file is faster than RDBMS, however, the persistency handling is done as part of the space's process. This means that the space process utilizes the machine CPU both for the space operations, and for interaction with the file. The file's persistency is also dependent on the space's life cycle – abnormal shutdown of the space might impact the file's coherency and consistency.
Wiki Content Tree
Your Feedback Needed!
We need your help to improve this wiki site. If you have any suggestions or corrections, write to us at firstname.lastname@example.org. Please provide a link to the wiki page you are referring to.