One of the most common topologies of GigaSpaces is a cluster of spaces with an external data source and a mirror service, which persist the data to the data source asynchronously. This is commonly known as write behind. Using this topology removes the bottleneck that the data source can create due to the obvious performance difference between the in memory data grid GigaSpaces provides and the persistence layer.

This topology can be used to hold only the most recently used entries in the data grid and keep the rest of the data in the data source. If a query is made and no matching entries for that query are present in the data grid, the query will be delegated to the data source and the matching entries will be loaded into the data grid and returned as the query result.

Such queries can be executed concurrently by many users of the data grid e.g. during the start up phase of the application, or when commonly used queries are executed by many concurrent clients. This can cause a noticeable access load on the data source. In order to optimize such scenarios, and reduce the load on the data source, we've introduced a new concept in version 7.0 named Shared Iterator.

A shared iterator optimizes the access to the data source by identifying queries which potentially share the same result set and exposing a facade to the multiple consumers of these queries.
This is done by returning an individual iterator for each consumer. Each consumer can iterate the result set at its own pace and consume a different number of results). Under the hood, the data grid only creates a single iterator on top of the data source, which consumes only a single connection to the data source, thus eliminating the contention that would have occurred otherwise. This feature is enabled by default and can be configured as described in this page (look for the space-config.external-data-source.shared-iterator.* properties)

Cheers,

Eitan Yanovsky
GigaSpaces XAP Core Team