Overview

This section discusses space write and read-through operations, and how to configure them by implementing the External Data Source interface or by using a standard Hibernate interface.

In this section:

• Read-through and write-through operations are discussed according to two main types of users: JavaSpaces API users and Map API users. (Both APIs use read-through and write-through operations with POJOs.)
• Each type of write and read is demonstrated, including single and multiple objects, transactions, and read/write in partitioned and replicated clustered spaces.
• The integration of the Hibernate interface into the read and write-through operations, and the Mirror space, which allows a space to "write-behind" asychronously to a data source, are described.
• The configuration and settings of the ExternalDataSource interface are described, including how to configure XML-based ORM mappings.

New in GigaSpaces 6.0

The External Data Source interface is new in GigaSpaces XAP 6.0. For the differences between performing read-through and write-through in version 5.2 and version 6.0, see the migration document.

Enterprise Data Fabric

External Data Source Interface – Middleware Link to Persistent Data Sources

The write and read-through operations and the External Data Source interface described in this section are an important part of the GigaSpaces concept of virtualizing and subsuming all the data sources required by an enterprise under one unified management, forming the Enterprise Data Fabric. The system can connect a running client application to such disparate data sources as local data caches, local and remote databases, clustered memory, message stores, and even remote running applications, all in a way that is transparent to the client application. The External Data Source interface is the key middleware connection link for loading and storing data to and from persistent data sources.

Virtualization of Tiers – Space-Based Architecture

Similar to the virtualization of data described above, GigaSpaces offers a space-based architecture (SBA) for processes, in which tiers are implemented as services within a shared runtime environment – regardless of the number of processing units actually involved – rather than as discrete tiers of presentation, business logic, and data access executing in autonomous runtimes.

Virtualization of the tiers (decoupling the physical entity from the logical entity) is a key strategy of space-based computing for achieving dynamic scalability.

In a SBA, virtualization of the tiers is achieved by grouping together the tiers required to process the application logic into a single logical processing unit. Scaling is achieved by running multiple instances of those units on multiple machines. In that way, the tiers are also spread between the machines and therefore become a virtual entity, i.e. there is no specific server that hosts a specific tier, but rather all machines host everything. It is the data and the load that are partitioned between the different units and enable the scaling-out. The overall efficiency with this architecture is also improved, since interaction between the tiers is handled within the same VM and there is no serialization/de-serialization overhead associated with it.

For more details, see Read-Through and Write-Through Overview.

Section Contents

• External Data Source Considerations — This section includes important notes when using the External Data Source interface.
• JavaSpaces API Write-Read Through
  • JavaSpaces API Read-Through — This section discusses client applications that use the JavaSpaces API to read Entry data from a space and, if the data is not found in the space, require the space to read from a different datasource.
  • JavaSpaces API Write-Through — This section discusses client applications that use the JavaSpace API to write Entry data to a space, and require the space to write the data to a different data source.
• Map API Write-Read-Through
  • Map API Read-Through — This section discusses client applications that use the Map API to read POJO data from a space and, if the data is not found in the space, require the space to read from a different data source.
  • Map API Write-Through — This section discusses client applications that use the Map API to write POJO data to a space, and require the space to write the data to a different data source.
• Read-Through and Write-Through Examples — Read-write-through examples with JDBC and Hibernate.
• Read-Through and Write-Through in Clustered Space — How the ExternalDataSource interface works in both partitioned and replicated clustered spaces.
• Read-Through and Write-Through Interface — About space write-through and read-through operations and how to configure them by implementing the ExternalDataSource interface.
• Read-Through and Write-Through Limitations — Read-Through and Write-Through – considerations, known issues and limitations.
• Read-Through and Write-Through Overview — Persisting space data into permanent storage; bridging the gap between object to relational; supported cluster topologies.
• Read-Through and Write-Through Settings and Configuration — The ExternalDataSource provides ability to control the life cycle of the datasource implementation.
• Read-Through and Write-Through Using Hibernate — Usage of the JavaSpace API, Map API, and Hibernate CacheLoader/Store driver for client applications.