Add caffeine cache implementation

[avdev4j]

#9

• Enable User Hibernate second level cache (Entity, relationships and methods)
• Enable Entity Hibernate second level cache (Entity and relationships)
• Enable Caffeine Quarkus cache (maven and gradle)
• Activate cache prompt with Caffeine
• Enable UserService cache through Quarkus impl
• Update CI
• Update npm tests
• CI is green
• set cache properties to default values for production purpose
• Add constants for maximum-size and expire-after-write properties
• Update application.properties for both User and Authority
• Add tests in server test generator test suite
• Add needle and needle-api for Quarkus application.properties
• Use needle api, every time we create a new Entity, to add maximum-size and expire-after-write properties
• Add tests in entity-server generator test suite

[avdev4j]

@nshaw @joewhite101
I was a little bit annoyed with duplication code issues in tests, I decided to create a "test context builder API" to have something modular and reusable. No more duplicated code, builder pattern based api, default and generic methods for main cases with the possibility to override context properties such prompts, options...

[avdev4j]

The Quarkus properties have not been added for the moment. We could do it by 2 ways:

• configuring user cache
• configuring each entity cache by using a needle (Quarkus needle in properties file) -> this mean we need to create a needle, test it...

I have no idea, if we should provide default configuration or not.

FYI in JHipster we have Java configuration that define default values provided by the JHipster framework: https://github.com/jhipster/generator-jhipster/blob/main/generators/server/templates/src/main/java/package/config/CacheConfiguration.java.ejs#L203 it's a bit different because this Java class configuration while we have properties configuration in Quarkus.

/discuss

[nshaw]

@avdev4j , 1) I like the test refactoring, less code especially in this area is always good. 2) I'd favor defaulting to prod-ready settings which would include a default cache configuration. (I assume a cluster-aware implementation, e.g. redis, is also on the roadmap.) I don't think I know enough in this area to comment on which option is better but providing a default will help get a developer one step closer to a full application.

[avdev4j]

I'd favor defaulting to prod-ready settings which would include a default cache configuration (I assume a cluster-aware implementation, e.g. redis, is also on the roadmap.)

This is my main issue right now. I think the best thing to do is to set caches with default values just like JHipster does.

quarkus.cache.caffeine.ENTITY.maximum-size=100
quarkus.cache.caffeine.ENTITY.expire-after-write=3600S

We need to do this for:

• User entity
• Authority entity
• Each generated Entity

I will do it tomorrow ;)

[nshaw]

Sounds like a good plan, thanks!

[avdev4j]

Oh and yes, we need to provide a least a solution for distributed cache implementation. Unfortunately, it seems Quarkus does not provide an abstraction for this kind of scenario. The only solution seems to be using a client librairie. I have in mind redis, Infinispan and Hazelcast.

I would like to do it for the next PR, It will be better to separate those from the current one.

[nshaw]

@joewhite101 probably has an opinion but we have Infinispan for Entando 6.2 and are adding redis for 6.3, so those would be my preferences, with Hazelcast in third place.

Definitely agree, doing that in its own PR makes sense. This one already has a lot.

[avdev4j]

I agree, according to main JHipster features I would say:

1. redis
2. infinispan (in beta in the main project)
3. Hazelcast (seems to be to less popular right now)

Redis seems to be quite used by cloud services too but I don't master this point so only suppositions.

[avdev4j]

How JHipster deal with Spring Cache in Main generator:

code layer: applicative cache --- hibernate 2nd level cache
                               |
             abstraction layer: Spring cache manager 
                               |
          implementation layer:  Caffeine, Redis, EhCache...

It's easy to understand that both applicative and hibernate 2nd level cache share the same implementation, so if we use a distributed or centralized one we can't have issue with synchronization between different instances.

Also, the code won't change because it will always use the Spring annotations, only the configuration part will be different according to the chosen solution.

Unfortunately, this is not possible in Quarkus. We have Quarkus cache but it has only one impl with Caffeine. If we use that with Hibernate 2nd level cache we would not have issue because everything is local.
Indeed, because Hibernate handles is own cache impl, we can't use it with distributed one.

For me we coud only do that :

• Allow hibernate 2nd level cache only with Caffeine or without cache aka 'no' (or any local caching solution in the future)
• Provide another caching solution outside Quarkus cache with client like Redis or Infinispan (will be done in another PR)

How JHipster Quarkus will deal with Caching:

On app generation

• You chose Caffeine: User and UserService have a Quarkus cache impl (userByLogin and userByEmail), application.properties has configuration set

    @CacheResult(cacheName = USERS_BY_LOGIN_CACHE)
    public static Optional<User> findOneWithAuthoritiesByLogin(String login) {
        return find("FROM User u LEFT JOIN FETCH u.authorities WHERE u.login = ?1", login)
            .firstResultOptional();
    }

    @CacheInvalidate(cacheName = User.USERS_BY_LOGIN_CACHE)
    public void clearUserCachesByLogin(String login) {}

    # configure your caches
    quarkus.cache.caffeine."usersByEmail".maximum-size=100
    quarkus.cache.caffeine."usersByEmail".expire-after-write=3600S
    quarkus.cache.caffeine."usersByLogin".maximum-size=100
    quarkus.cache.caffeine."usersByLogin".expire-after-write=3600S

• You chose Hibernate 2nd level cache: User and Authority have annotations

    @Entity
    @Table(name = "jhi_user")
    @Cacheable
    public class User extends PanacheEntityBase implements Serializable {};

    @Cache(usage = CacheConcurrencyStrategy.READ_ONLY)
    @BatchSize(size = 20)
    public Set<Authority> authorities = new HashSet<>();

On entity generation e.g. foo

For this part nothing will be done with Caffeine, it's up to developer to do something close we have in User/UserService. Applicative cache is more related to business logic.

• Hibernate second level cache is selected: The entity has all annotations, we add properties for each cache in application properties (relationship includes)

    @Entity
    @Table(name = "foo")
    @Cacheable
    @RegisterForReflection
    public class Foo extends PanacheEntityBase implements Serializable {}

    @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
    public Set<Label> labels = new HashSet<>();

    quarkus.hibernate-orm.cache."io.github.jhipster.sample.domain.Foo".expiration.max-idle=3600S
    quarkus.hibernate-orm.cache."io.github.jhipster.sample.domain.Foo".memory.object-count=100
    quarkus.hibernate-orm.cache."io.github.jhipster.sample.domain.Foo.labels".expiration.max-idle=3600S
    quarkus.hibernate-orm.cache."io.github.jhipster.sample.domain.Foo.labels".memory.object-count=100

[avdev4j]

@nshaw @joewhite101 @danielpetisme

I wrote this documentation to explain a bit more how this works, hope it will help (we could update the readme to add that).

[danielpetisme]

LGTM, Awesome work

[danielpetisme]

Regarding the caching doc, should it be done in the README.MD or in an external documentation

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication