The JUG Saxony Camp 2017 was organized by the JUG Saxony e.V. and took place at the HTWK Leipzig University of Applied Sciences.
Prerequisites:
- WildFly AS
- Maven
public class CacheDemo {
@CacheResult
public int someExpensiveCalculation(int argOne, String argTwo) {
return new Random().nextInt();
}
}
Our aim is to temporary store the return value of our business logic. Therefore we annotate the method with @CacheResult, which is part of the JCache API (JSR-107). The WildFly AS provides an out of the box JCache implementation called Infinispan.
In the directory code/jug.saxony.camp.jcache you can find a prototype, which uses Infinispan's CacheResultInterceptor. The JAR contains the business logic of our application, the WAR a servlet, and the EAR unites both for deployment.
$ cd code/jug.saxony.camp.jcache
$ mvn clean install
Now you are able to deploy the EAR on WildFly AS.
This servlet demonstrates, that our cache works as expected.
But this solution brings some problems:
-
This cache isn't resistent against redeployment of your EAR, in case you might edit your view component.
-
The storage of this cache is not under control of WildFly, so two applications aren't able to scale their performance by using a common cache.
The following caching technique will show you, how to solve this problems.
Under code/jug.saxony.camp.infinispan.embedded you find a prototype, that has a custom implementation of JCache's CacheResultInterceptor. This interceptor uses Infinispan's embedded caching framework, which is independent from JCache. Thus this technique is able to reference WildFly's preconfigured caches.
$ cd code/jug.saxony.camp.infinispan.embedded
$ mvn clean install
Deploy the EAR to your WildFly instance and again access it's servlet. Redeploy this application and you will see, that the returned values remain the same. When you deploy a second instance of the application with a customized servlet, you will observe, that both share the common cache instance.