This guide walks through the process of using the Apache Geode's data management system to cache certain calls from your application code.
|
Tip
|
For more general knowledge of Apache Geode concepts and accessing data from Apache Geode, read through the guide, Accessing Data with Apache Geode. |
You’ll build a service that requests quotes from a CloudFoundry hosted Quote service and caches them in Apache Geode.
Then, you’ll see that fetching the same quote again eliminates the expensive call to the Quote service since Spring’s Cache Abstraction, backed by Apache Geode, will be used to cache the results, given the same request.
The Quote service is located at…
https://quoters.apps.pcfone.io
The Quote service has the following API…
GET /api - get all quotes
GET /api/random - get random quote
GET /api/{id} - get specific quote
For all Spring applications, you should start with the Spring Initializr. Spring Initializr offers a fast way to pull in all the dependencies you need for an application and does a lot of the set up for you. This example needs "Spring for Apache Geode" dependency.
The following listing shows an example pom.xml file when using Maven:
link:complete/pom.xml[role=include]
The following listing shows an example build.gradle file when using Gradle:
link:complete/build.gradle[role=include]
Now that you’ve set up the project and build system, you can focus on defining the domain objects necessary to capture the bits you need to pull quotes (the data) from the Quote service.
src/main/java/hello/Quote.java
link:complete/src/main/java/hello/Quote.java[role=include]The Quote domain class has id and quote properties. These are the two primary attributes you will gather
further along in this guide. The implementation of the Quote class has been simplified by the use of
Project Lombok.
In addition to Quote, the QuoteResponse captures the entire payload of the response sent by the Quote service
sent in the quote request. It includes the status (a.k.a. type) of the request along with the quote. This class
also uses Project Lombok to simplify the implementation.
src/main/java/hello/QuoteResponse.java
link:complete/src/main/java/hello/QuoteResponse.java[role=include]A typical response from the Quote service appears as follows:
{
"type":"success",
"value": {
"id":1,
"quote":"Working with Spring Boot is like pair-programming with the Spring developers."
}
}Both classes are marked with @JsonIgnoreProperties(ignoreUnknown=true). This means even though other JSON attributes
may be retrieved, they’ll be ignored.
Your next step is to create a service class that queries for quotes.
src/main/java/hello/QuoteService.java
link:complete/src/main/java/hello/QuoteService.java[role=include]The QuoteService uses Spring’s RestTemplate to query the Quote service’s API.
The Quote service returns a JSON object, but Spring uses Jackson to bind the data to a QuoteResponse and ultimately,
a Quote object.
The key piece of this service class is how requestQuote has been annotated with @Cacheable("Quotes").
Spring’s Caching Abstraction
intercepts the call to requestQuote to check whether the service method has already been called. If so, Spring’s
Caching Abstraction just returns the cached copy. Otherwise, Spring proceeds to invoke the method, store the response
in the cache, and then return the results to the caller.
We also used the @CachePut annotation on the requestRandomQuote service method. Since the quote returned from
this service method invocation will be random, we don’t know which quote we will receive. Therefore, we cannot consult
the cache (i.e. Quotes) prior to the call, but we can cache the result of the call, which will have a positive
affect on subsequent requestQuote(id) calls, assuming the quote of interest was randomly selected
and cached previously.
The @CachePut uses a SpEL expression (“#result.id”) to access the result of the service method invocation
and retrieve the ID of the Quote to use as the cache key. You can learn more about Spring’s Cache Abstraction
SpEL context here.
|
Note
|
You must supply the name of the cache. We named it "Quotes" for demonstration purposes, but in production, it is recommended to pick an appropriately descriptive name. This also means different methods can be associated with different caches. This is useful if you have different configuration settings for each cache, such as different expiration or eviction policies, etc. |
Later on when you run the code, you will see the time it takes to run each call and be able to discern the impact that caching has on service response times. This demonstrates the value of caching certain calls. If your application is constantly looking up the same data, caching the results can improve your performance dramatically.
Although Apache Geode caching can be embedded in web apps and WAR files, the simpler approach demonstrated below
creates a standalone application. You package everything in a single, executable JAR file, driven by a good old Java
main() method.
src/main/java/hello/Application.java
link:complete/src/main/java/hello/Application.java[role=include]At the top of the configuration is a single, vital annotation: @EnableGemfireCaching. This turns on caching (i.e. is
meta-annotated with Spring’s @EnableCaching annotation) and declares additional, important beans in the background
to support caching using Apache Geode as the caching provider.
The first bean is an instance of QuoteService used to access the Quotes REST-ful Web service.
The other two are needed to cache Quotes and perform the actions of the application.
-
quotesRegiondefines a Apache GeodeLOCALclient Region inside the cache to store quotes. It is specifically named "Quotes" to match the usage of@Cacheable("Quotes")on ourQuoteServicemethod. -
runneris an instance of the Spring BootApplicationRunnerinterface used to run our application.
The first time a quote is requested (using requestQuote(id)), a cache miss occurs and the service method
will be invoked, incurring a noticeable delay that is no where close to zero ms. In this case, caching is linked by
the input parameters (i.e. id) of the service method, requestQuote. In other words, the id method parameter is
the cache key. Subsequent requests for the same quote identified by ID, will result in a cache hit, thereby avoiding
the expensive service call.
For demonstration purposes, the call to the QuoteService is wrapped in a separate method (requestQuote inside the
Application class) to capture the time to make the service call. This lets you see exactly how long any one request
is taking.
Logging output is displayed. The service should be up and running within a few seconds.
"@springboot with @springframework is pure productivity! Who said in #java one has to write double the code than in other langs? #newFavLib" Cache Miss [true] - Elapsed Time [776 ms] "@springboot with @springframework is pure productivity! Who said in #java one has to write double the code than in other langs? #newFavLib" Cache Miss [false] - Elapsed Time [0 ms] "Really loving Spring Boot, makes stand alone Spring apps easy." Cache Miss [true] - Elapsed Time [96 ms]
From this you can see that the first call to the Quote service for a quote took 776 ms and resulted in a cache miss. However, the second call requesting the same quote took 0 ms and resulted in a cache hit. This clearly shows that the second call was cached and never actually hit the Quote service. However, when a final service call for a specific, non-cached quote request is made, it took 96 ms and resulted in a cache miss since this new quote was not previously in the cache before the call.
Congratulations! You’ve just built a service that performed an expensive operation and tagged it so that it will cache results.