Overview

This section describes how the CacheLoader/Store Interface works in both partitioned and replicated clustered spaces.

To enable logging for CacheLoader\Store, edit the <GigaSpaces Root>\config\gs_logging.properties file and set the persistent level to CONFIG or FINER. For more details, refer to the Settings & Configuration section.

Partitioned Clustered Space

Read-Through in Partitioned Clustered Space

The two diagrams above illustrate how a client application reads from a partitioned clustered space, where the actual data is loaded from a distributed or a central data source or other external application. The total of data stored inside the clustered space is divided into two physical partitions, each in a different JVM, where one of the fields value hashcode inside the Entry determines the partition that stored the Entry.

Each Entry stored inside the primary partition is backed up in a separate dedicated space for continuous uninterrupted operation in case of "hot failover". In any case, the data is also stored in the database. Each space partition has a CacheLoader implemented allows the space to load relevant data from the database.

When a partitioned space works with a central data source, each partition is protected from reading data from the database that does not reside in that partition.

The operation proceeds in two stages:

1. The client application calls the JavaSpace API read to get the object A.
   An example for the client application call:

   Person template = new Person();
   template.setId(ID);
   template.setFirstName("firstName");
   Person person = (Person)space.read(template, null, timeout);

2. The JavaSpaces API uses the template.id hashcode to route the operation to Partition 1 and initiates data lookup in the that partition for a matching Entry. The first matching Entry found from the Person class or its sub-classes instances is returned. If no such Entry is found, the CacheLoader interface method load in Partition 1 is called by the space, passing a parameter IGSEntry that encapsulates the template data. The load method gets the required record data from the database, creates a relevant Person object with the Person class data and returns it back to the space as IGSEntry. The space returns the result Entry in Entry format to the client implicitly.

Similarly, object B is read first from Partition 2 using a relevant template. If it is not found, it is read from the database by the partition's CacheLoader.load method.

Optimistic locking mode is not supported when using CacheLoader/Store.

Write-Through in Partitioned Clustered Space

The two diagrams above illustrate how a client application writes to a partitioned clustered space and persists the data in a distributed or central database, or another external application. Each partition has a CacheStore implementation that provides the space the ability to store the data into the database.

The operation proceeds in two stages:

1. The client application calls the JavaSpace API write method to write object A.
   An example for the client application call:

   Lease lease = space.write(person, null, Lease.FOREVER);

2. The JavaSpace API uses the person ID field hashcode to determine that Entry A should be located in Partition 1, and writes A into that partition. The Entry A is then backed up in the dedicated space in JVM 1. The CacheStore interface method store in partition 1 is called by the space, passing a parameter IGSEntry that encapsulates the original data. The store method writes the required data to the database in record format.

Similarly, object B is written first to Partition 2, backed up in the dedicated space in JVM 4, and written to the database by the partition's CacheStore.store method.

Make sure the <fail-over-policy> is not used as part of the partitioned schema, or have the failover <policy-type> to be fail to backup. Not having the above settings will result in an incorrect data load from the database, and incorrect data in the partitions.

A partitioned space using the CacheLoader/Store implementation with a central database should have the following displayed when started:

Life-cycle properties:
         Supports inheritance: true
         Supports versioning:  false


schema-xml configuration:
<persistent>
         <CacheLoaderClass>com.gigaspaces.hibernate.HibernateCacheStoreImpl</CacheLoaderClass>
         <StorageAdapterClass>com.j_spaces.sadapter.cache.CacheAdapter</StorageAdapterClass>
         <entity-class></entity-class>
</persistent>
cluster-xml configuration:
<cache-loader>
         <external-data-source>true</external-data-source>
         <central-data-source>true</central-data-source>
</cache-loader>

Replicated Clustered Space

This section shows how the CacheLoader/Store interface works in a replicated clustered space.

Read-Through in Replicated Clustered Space

The two diagrams above illustrate how a client application reads from a replicated clustered space where the actual data is loaded from a distributed or a central data source or another external application. Each space has a CacheLoader implementation that provides the space the ability to load data from the database when it is not found inside the space.

The operation proceeds in two stages:

1. Entry B was previously written to Location 2 and replicated to Location 1.
2. The client application in Location 1 calls the JavaSpaces API read to get the object A.
   An example for the client application call:

   Person person = (Person)space.read(templateA, null, timeout);

3. The space initiates data lookup in the space at Location 1, for a matching Entry. The first matching Etry found from the Person class or its sub-classes instances is returned. If no such Entry is found, the CacheLoader interface method load in Location 1 is called by the space, passing a parameter IGSEntry that encapsulates the template data. The load method gets the required record data from the database and returns it back to the space. The space returns the result Entry in Entry format to the client implicitly.
4. Entry B is read by the client application from the space at Location 1, where it reads the copy of Entry B that was replicated from the original in Location 2. If not found, it is read from the database by the space CacheLoader.load method.
   For a distributed database, the database in each location maintains a copy of all the data in both locations, so that a client application backs up and retrieves data from the database in the nearest location.

Write-Through in Replicated Clustered Space

When a replicated space is using the CacheLoader implementation with a central data source configuration, write, take, or update operations are not replicated from the primary space to the backup spaces.

Once the backup space becomes active and applications can access it directly, it will load data from the database using its own CacheLoader implementation. This ensures data coherency and provides better performance.
When using replicated space using CacheLoader implementation with a non-central data source configuration – i.e. each space uses different database instance, the write, take, or update operations are replicated from the primary space to the backup spaces, and persistent into the backup space database.

In both configurations, when data is loaded into the active space from the database using its CacheLoader, the loaded Entries are not replicated into replica spaces.

Configuration

When a clustered space is using the CacheStore/Loader implementation, you should start all nodes using the following property:

com.gs.cluster.cache-loader.external-data-source=true

When a clustered space is using Central for all nodes, you should start all nodes using the following property:

com.gs.cluster.cache-loader.central-data-source=true

When a clustered space is using different database instances for each space instance, you should start each node using the following property:

com.gs.cluster.cache-loader.central-data-source=false