GemfireTemplate with ClientRegionShortcut.CACHING_PROXY_HEAP_LRU doesn't cache locally

Question

clientCache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY_HEAP_LRU) works as expected when used with a spring-cache GemfireCacheManager and caches data locally.

However when the same settings is used in conjunction with GemfireTemplate, to use Gemfire as a repo instead of a cache, doesn't seem to be caching data locally at all and always fetches back from server.

I'm storing value as a small Hashmap and have tried increasing heap memory to -Xms1024m -Xmx2148m to nullify the effect of less heap memory with no effect.

What am I missing?

Answer 1

First, why would you (possibly?) be using GemFire's API to create a client Region with ClientCache.createClientRegionFactory(:ClientRegionShortcut), especially in a Spring context? To properly manage the lifecycle of GemFire objects in a Spring context, you you should be using Spring Data GemFire, and SDG's configuration, either XML or (preferably) Annotation-based.

Second, this...

However when the same settings is used in conjunction with GemfireTemplate, to use Gemfire as a repo instead of a cache, doesn't seem to be caching data locally at all and always fetches back from server.

Is rather weak argument. What makes you think it "doesn't seem to be" caching data locally?

Have you observed output in GemFire's log to support your claim? Have you written a test to confirm your assumption? What is your Spring (?) configuration to configure GemFire in a Spring context along with acquiring access to the Region via the GemfireTemplate? What version of Spring Data GemFire are you using? Etc, etc.

Do you understand that the GemfireTemplate is a wrapper for a GemFire Region (which uses the Template Software Design Pattern, serving the same purpose as Spring's JdbcTemplate)? Any GemfireTemplate.put(key, value) operation effectively calls Region.put(key, value).

NOTE: Using various Spring template's enables your application's data access operations to be conveniently decorated with additional capabilities, such as translating data store-specific Exceptions (e.g. GemFire, and often erroneously "Checked" Exceptions) in Spring's all important Data Access Exception Hierarchy along with enabling your application data access operations to properly participate in a Transaction when inside a Transactional scope, without having to write boilerplate code like tx.begin() and either tx.commit() or tx.rollback(). Anyway...

So, even if your code look somewhat like this...

RegionFactory exampleRegionFactory = clientCache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY_HEAP_LRU);

// 1. call various setters to configure the Region created by the factory
exampleRegionFacatory.set...
...

// 2. create the Region
Region exampleRegion = exampleRegionFactory.create("Example");

// 3. interface to the Region via the GemfireTemplate
GemfireTemplate exampleTemplate = new GemfireTemplate(exampleRegion);

// 4. put key/value into /Example Region
examleTemplate.put("myKey", "myValue");

How is that any different than, instead of 4, just this...

exampleRegion.put("myKey", "myValue");

And finally, consider this test class I wrote...

This test class is based on Spring Data GemFire 2.0.1.RELEASE.

This test class includes a Gfsh shell script to start up a small GemFire cluster (a Locator and Server) and to inspect the server after each test run, if you prefer. However, in order to inspect the state of the server after a test run, you will need to comment out this line. But then, you must remember to wipe the data on the server before your next test run using remove --region=/Example --key=testKey otherwise, this assertion will fail, obviously!

As you can see, I have the client Region data policy set with the ClientRegionShort.CACHING_PROXY_HEAP_LRU (as you stated above). You can experiment with different ClientRegionShortcuts to see their effect. This test class will pass with all ClientRegionShortcuts except for ClientRegionShortcut.PROXY (which, of course, does not store any data "locally" in the client's Region, therefore has NO size). With the LOCAL-only based ClientRegionShortcuts, you don't need to run a server.

finally, I have created 2 Spring Profiles, the Spring Data GemFire Annotation-based configuration approach (Profile "Spring Data GemFire"), along with the GemFire API-based approach (Profile "GemFireApi"). Don't ever use the later, especially in a Spring context. I wrote this profile to purely demonstrate that if you are using the snippet of client Region configuration from above, it will still work!

You can switch profiles using the Spring TestContext @ActiveProfiles annotation, like so.

One last thing to note, the Region.size() method only consider the local (client) Region's size as explained in the Javadoc, where as the Region.sizeOnServer() will inspect the corresponding (by name) server Region's size (Javadoc).

This test passes as expected!

Hope this helps!

-John