Summary: Using JDBC Storage Adapter with OpenSpaces to achieve Durability.

Overview

GigaSpaces JDBC Storage Adapter supports implicit data recovery from the database when a space is started, stores Entry meta data, and persists a redo log. The data source and space are constantly synchronized with each-other. More information can be found at Persistent Space Schema and Persistency Configuration Files.

Note, configuration of the JDBC storage adapter is now consolidated and can be completly controlled within OpenSpaces space tag.

Configuration

Configuring a JDBC storage adapter is done using properties within the Space construction. Here is an example of storing the information within HSQL:

Namespace
<os-core:space id="space" url="/./space" schema="persistent">
    <os-core:properties>
        <props>
            <!-- Properties that control the persistent schema -->
            <prop key="space-config.persistent.StorageAdapterClass">
                   com.j_spaces.sadapter.GenericJDBC.JDBCStorageAdapter
            </prop>
            <prop key="space-config.persistent.StorageAdapterURL">config/GenericJDBCProperties/HSQLProperties</prop>
            <!-- override hsql default properties (found under jdbc.properties) -->
            <prop key="userName">sa</prop>
            <prop key="password"></prop>
            <prop key="connectionUrl">jdbc:hsqldb:hsql://localhost:9001</prop>
        </props>
    </os-core:properties>
</os-core:space>

Plain XML
<bean id="space" class="org.openspaces.core.space.UrlSpaceFactoryBean">
    <property name="url" value="/./space" />
    <property name="schema" value="persistent" />
    <property name="properties">
        <props>
            <!-- Properties that control the persistent schema -->
            <prop key="space-config.persistent.StorageAdapterClass">
                   com.j_spaces.sadapter.GenericJDBC.JDBCStorageAdapter
            </prop>
            <prop key="space-config.persistent.StorageAdapterURL">/GenericJDBCProperties/HSQLProperties</prop>
            <!-- override hsql default properties (found under jdbc.properties) -->
            <prop key="userName">sa</prop>
            <prop key="password"></prop>
            <prop key="connectionUrl">jdbc:hsqldb:hsql://localhost:9001</prop>
        </props>
    </property>
</bean>

Differences between the JDBC SA and the EDS

Here is a list that compares the JDBC SA and the External Data Source:

  • Data Aging (Lease behavior) - with External Data Source, expired objects with a finite lease are not removed from the database; however with JDBC SA, they are removed from the database. This means that with the External Data Source you can implement data aging in very simple manner. Just write objects into the IMDG with the relevant time-to-live (lease time) and let the IMDG persist the data into the database and keep it in memory for a specific, known duration of time. This is very common behavior with trading, telecom, datacom and mobile data systems.
  • Initial-Load Behavior - by default, with the External Data Source, every primary instance of the IMDG loads its data from the database (this is called the "initial load phase") and later replicates it to the backup instance. The External Data Source support parallelizes data loading, which might speed up the initial load phase substantially. You can also control which type of classes of data will be loaded - in fact you can implement your own business logic for the initial loading. The JDBC SA does not support these capabilities. It does have the initial load phase which pre-load data from the database , but you can't control it and both the primary and the backup loading their data from the database from different tables.
  • Replication Status - when running with External Data Source, the replication status (redo log) is stored in memory. The JDBC SA stored this data in the database; this impacts the performance.
  • IMDG Cluster Behavior - when running with External Data Source, you can have the same database used both for primary and backup. This means that write activity to the database is done only once. With the JDBC SA, you have data stored in different tables (and possibly a different database server) for the primary and backup. This has a large impact on performance.
  • Data Eviction Behavior - the IMDG supports two main eviction modes. One model has no eviction (ALL IN CACHE); the other evicts last recently used objects (LRU). In LRU mode, data is evicted based on a maximum number of IMDG objects and also based on free memory. There is very little control to determine which objects will be evicted, due to the nature of the LRU policy. When running in this mode, IMDG queries are translated into database queries. When a matching object is not found in the IMDG , the IMDG automatically generates the relevant database query (via the mapping layer, i.e., a Hibernate query using the database dialect) and loads relevant data back into the IMDG. When there are several objects found in the database, these are loaded via a pagination mechanism. With EDS you can control this process. The JDBC SA does not allow you to control it and does not support custom query generation.
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence