Overview

You may persist the space data into an indexed file. The indexed file holds the space data in memory for small durations and periodically flushes changes into an indexed file. Data flushing into the file occurs in the following cases:

• When space transaction commit is called.
• When the Check_Point_Period is defined – The Check_Point_Period specifies a time[ms] to wait between flush operations. You can specify a time interval to flush the file cache into the disk. The default value for this parameter is -1 – i.e., No periodic flush into disk.
• When Number_Sync_Objects has elapsed – Number of destructive operations to happen (i.e., write, take) before flushing the file cache into the disk. File cache data will be flushed into the disk after a specified number of destructive space operations has been called. The default value for this parameter is -1 – i.e., No flush into disk.

Enum Data Types Support In GigaSpaces version 5.0, Enum data types are not supported by the JDBC Storage Adapter, and are supported by the indexed file persistency. In GigaSpaces version 5.1 and onwards, both the JDBC Storage Adapter and the indexed file persistency support Enum data types.

Indexed File Persistency Doesn't Support Jini Transactions The indexed file persistency does not support Jini transactions – use local transactions or RDBMS persistency instead.

Creating a Persistent Space with the Generic Adapter

You may create a space that will persistent its data into the indexed file using the persistent or the swap space schemas.

Starting up All Cluster Nodes in the Right Order when Using Persistent Space When running a 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 is synchronized with the primary space's latest data (underlying database). Starting the backup spaces first leads 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.

Using the command line

To start a space using the persistent schema, run the following command:

gsServer "/./myPersistentSpace?schema=persistent"

To start a space using the swap schema run the following command:

gsServer "/./myPersistentSpace?schema=swap"

Using the Space browser

To create a persistent space using the space browser:

1. Start the space instance or space container.
2. Start the GigaSpaces Space Browser.
3. Right-click your container icon and select Create Space.
   The Create New Space dialog opens:
   
4. Provide a space name, for example, myPersistentSpace.
5. Select the Persistent schema from the Schemas list. The Persistent check-box will be selected and the com.j_spaces.sadapter.GenericPA.GenericPersistentAdapter will be selected with the Storage Adapter class.
6. Make sure the ../GenericPersistProperties is selected as part of the Storage Adapter URL.
7. Click the Advanced button at the bottom of the dialog and on the Performance tab make sure that No Serialization is selected as part of the Serialization mode.
8. On the Memory Management tab make sure the LRU Cache policy is selected.
9. Press the Create button.

After clicking Create, you will notice that on the Space server side <GigaSpaces Root>/GenericPersistProperties/, a folder with a directory has the same name as your container plus the newly created space, e.g., myCache_container_myPersistentSpace. This folder will store the indexed file.