You may persist the space data into any JDBC 2.0 compliant database. When using this option, the space maps space Entries into relational database tables using classic object to relational mapping rules:
Each Entry class type is mapped into a dedicated database table.
Every Entry class public attribute is mapped into its relevant SQL column type.
Each Entry object is mapped by default to one row in the relevant table.
If your class is inherited from another class, the table generated for your class contains inherited class attributes together with current class attributes, where class attributes are stored in a separate column.
Non-Native Java attributes (user-defined class attributes) are serialized and stored within one blob type column.
The space generates several tables for each space that stores space metadata. You may use the same database to persist several spaces data. The database will include different tables for each space using a different table prefix assigned for each space.
When running persistent cluster using the primary_backup or the partitioned-sync2backup schemas, and starting up all cluster nodes, primary spaces – the spaces that were running as active before the cluster was shut down, must be started first, and the backup spaces must be started second.
In this way, when the backup space is started, it will synchronize with the primary space's latest data (underlying database).
Starting the backup spaces first will lead to data loss and inconsistent data.
This limitation is relevant when using GigaSpaces version 5.0.
When using GigaSpaces version 5.1 and onwards, you may control this behavior using the following property: com.gs.cluster.replication.secure-restart=true.
We need your help to improve this wiki site. If you have any suggestions or corrections, write to us at techw@gigaspaces.com. Please provide a link to the wiki page you are referring to.
Previous release
Add Comment