How Data Loaders Work
By default, a region has no data loader defined. Plug an application-defined loader into any region by setting the region attribute cache-loader on the members that host data for the region.
A loader can be configured to load data into the Tanzu GemFire cache from an outside data store. To do the reverse operation, writing data from the Tanzu GemFire cache to an outside data store, use a cache writer event handler. See Implementing Cache Event Handlers.
How to install your cache loader depends on the type of region.
Because of the huge amounts of data they can handle, partitioned regions support partitioned loading. Each cache loader loads only the data entries in the member where the loader is defined. If data redundancy is configured, data is loaded only if the member holds the primary copy. So you must install a cache loader in every member where the partitioned attributes
local-max-memory is not zero.
If you depend on a JDBC connection, every data store must have a connection to the data source, as shown in the following figure. Here the three members require three connections. See Configuring Database Connections Using JNDI for information on how to configure data sources.
Note: Partitioned regions generally require more JDBC connections than distributed regions.
In a non-partitioned distributed region, a cache loader defined in one member is available to all members that have the region defined. Loaders are usually defined in just a subset of the caches holding the region. When a loader is needed, all available loaders for the region are invoked, starting with the most convenient loader, until the data is loaded or all loaders have been tried.
In the following figure, these members of one cluster can be running on different machines. Loading for the distributed region is performed from M1.
For local regions, the cache loader is available only in the member where it is defined. If a loader is defined, it is called whenever a value is not found in the local cache.