Quarkus: Extension: Panache-Infinispan (Panache-Ignite)

[nimo23]

I see that quarkus has Infinispan Embedded/Client extensions but I cannot see the general JCache support of quarkus.

I find there could be something like PanacheStorage or PanacheCache with the same idea/handling of PanacheEntity: simplify overall caching (plugging, storing, querying) with different caching providers (e.g., Apache Ignite, Infinispan, Hazelcast) by extending a class and annotating it with JCache-Annotations.

_Btw, I tried to include Apache Ignite (https://ignite.apache.org/features/datagrid.html) but it does not run out of the box in quarkus. I think, it can only run when having a quarkus-ignite extension. Besides the support of JCache (JSR 107), Apache Ignite also provides native persistence by switching from ACID-caching to ACID-persisting which eliminates the need for a typical database provider (such as MySql, etc). It also supports embeeded mode._

[loicmathieu]

@nimo23 application cache is discussed in the following issue: https://github.com/quarkusio/quarkus/issues/3306

It has been decided to go for an annotation based cache and NOT compatible with JCache API.
You can show your interest on this functionality by adding a +1 to the issue and contribute to the discussion :)

If you think that an Apache Ignite extension will be a good addition, you can open an extension proposal issue about it.

[nimo23]

I read the issue and dont like it..why does "quarkus do homebrew again" instead of focusing or improving jakarta specs. If jcache has limitations, then please consider to improve it by contributing to the spec instead of doing homebrew and splitting the community. Why not using already established jcache providers and simplifiying the use in Quarkus with PanacheCache (with the same idea as PanacheEntity does it with JPA/Hibernate).

"it comes with a lot of baggage"-arguments sounds stupid. Re-inventing the wheel which will also lead to bugs and feature requests in the future will add the "baggage" in future what quarkus wanted to avoid. And users must wait till quarkus reaches the point what those specs already reached. Btw, it would be far better for quarkus to treat itself as the "glue" between those jakarta/mp specs and invent some coding helpers (such as PanacheEntity, etc.) or general improvements instead of re-inventing the wheel (for example, qute<->Jakarte EL/JSF, quarkus-cache<->jcache, quarkus-security<->Jakarta Security, etc.). I dont like to see quarkus as a subset of jee/mp specs with handicaps, implicit limitations and homebrew soup trying to replace jee/mp specs. I like to see quarkus as the next step of thorntail/wildfly which complies or contribute to jee/mp-specs.

[Sanne]

If jcache has limitations, then please consider to improve it by contributing to the spec instead

We have tried that in the past. Several people who are contributing ideas and design on #3306 have previously worked on the JCache spec, and even some of the implementations; for example both Galder and myself have worked for 10+ years on Infinispan, and we have had conversations with many other smart people from the caching community including Ignite, cache2k, caffeine, ehcache - feels like lots of friends in the club :)

So this is about an evolution and trying to not repeat some mistakes as we learned some things - the original spec was designed a very long time ago and needs a refresh; there's hope that showing the other experts in the field a new simplified API will influence the next version of the spec.

Keep in mind also the proposal on #3306 is intentionally extremely limited in scope, so that we can evolve later (with caution).

[tandraschko]

@nimo23 +1 for you comments here

[emmanuelbernard]

So "PanacheCache" is not a fully clear idea for me but I think it is the quarkus cache annotations and the upcoming programmatic API. For local cache, I don't see much value is setting a swapping ability compared to the caffeine based solution we have. It will keep config and mental overhead to a minimal.

For some abstraction over a remote cache, that's something we should explore but the first step is to get the client side of the remote cache have its own extension like Infinispan has.

For JCache, I did challenge people a lot on "why not JCache?" while we were building the annotations and they did all consistently push back, there is another GitHub issue and email threads with lengthy conversations. If someone feels JCache must be there as an API, the solution is to write a JCache extension and host it like the camel ones, the QPid one, the Debezium one on its own Git repo and have them published in the platform metadata to be available on code.quarkus.io and other tools. The rule for an extension is that it must support native image.

[nimo23]

So "PanacheCache" is not a fully clear idea

@emmanuelbernard Let me describe it in another way:

Actually, I have a lot of entities with a lot of relationships defined by Hibernate and JPA annotations. The domain model is well designed and the binding between the entities and the sql database with all the defined jpa queries works.

I only have one bottleneck: performance (in relation to speed/latency/save/update), not because of Hibernate but because of the underlying SQL-database.

Using Hibernate-Cache is not a fully solution and something like quarkus-cache cannot help - because it is only _warm_ caching which is lost after restarts and not tightly coupled to the domain model (https://github.com/quarkusio/quarkus/issues/6947).

I need someting more, so I must switch to either Jboss Infinispan or Apache Ignite and unfortunately, all the well designed hibernate/jpa annotations cannot be reused for those two database providers. I say _database-providers_ because both _Jboss Infinispan_ and _Apache Ignite_ not only provide pure caching solution but also a very fast (write-behind, disk-based, cold cache) storage solution wich also complies to the transaction level normally used on pure sql databases (Infinispan: READ_COMMITTED and REPEATABLE_READ, Apache Ignite: also supports SERIALIZABLE).

Jboss Infinispan has its own query language named "Ickle" (inspired by JP-QL) but its storage solutions ("Single File Cache Store" and "Soft-Index Cache Store") called "Cache Stores" are by far not better than that with Apache Ignite (which also provides strong ACID and SQL, https://apacheignite-sql.readme.io/docs/overview).

Long story short: the best would be if Hibernate has an additional dialect/driver to support Apache Ignite/Infinispan. But that's not the case and I think it will never be. Hibernate OGM is also not whished for quarkus https://github.com/quarkusio/quarkus/issues/6514.

So the only viable solution for this problem is to provide an extension. Quarkus has already simple support for Infinispan and Kafka. I say Kafka, because it can also be seen as a database (event-streaming database with setting the retention to "forever" and enabling "log compaction", https://github.com/quarkusio/quarkus/issues/7074).

But I will focus further on Apache Ignite. Because in compare to others it is simply the best replacement for a typical sql database. I already opened an issue to support Apache Ignite: https://github.com/quarkusio/quarkus/issues/6986

But here we come to PanacheCache as the glue between the JPA/Hibernate annotated domain model with all its relationships and jpql queries and those warm/cold-caching solutions (Apache Ignite). Maybe a better naming for PanacheCache would be "PanacheStore".

The main features what PanacheStore supports:

• a full replacement for typical SQL databases (backed by ApacheIngite or Infinispan)
• usable for warm/cold caching (backed by ApacheIngite or Infinispan)
• full serialization support (backed by, for example Avro, ProtoBuf, MessagePack) to transport those entities in a fast and compact form over the wire (instead of json/rest)
• and all those backed by JPA/Hibernate/PanacheStore annotations.

[Sanne]

hi @nimo23 , let me give you a little more context: @emmanuelbernard and myself helped create Infinispan an design the Ickle language. We also started the Hibernate OGM project for similar reasons to what you describe :+1: , and during the OGM development we had the opportunity to work a bit with Ignite as well.

So no need to explain those points and why it would be cool to have them :)

But it's still unclear what PanacheCache is; now you mention PanacheStore: do you mean a repository abstraction for NoSQL ? How would the API look like?

Also, aren't you rather suggesting you need a way to warmup the JPA caches? That could be done I believe.

[nimo23]

We also started the Hibernate OGM project for similar reasons to what you describe

Wow, very cool I did not know that 👍

do you mean a repository abstraction for NoSQL ? How would the API look like?

Yes, it is an abstraction but only focused on ApacheIgnite (and Infinispan). No other NoSql-storages!

How would the API look like?

• the API is backed by JPA/Hibernate/PanacheStore annotations
• the JPA entityManager with its transactional concept (by @Transactional) is used
• query support by JPQL
• models are annotated by common jpa/hibernate annotations
• PanacheStore annotations are used for those places which cannot be filled by the already existing JPA/Hibernate annotations
• raw access to ApacheIgnite and Infinispan is provided by CDI injection
• automatic schema creation/validation for serialization support (e.g., ProtoBuf, Avro) backed by the annotated jpa entities

[nimo23]

I find it would be better to rename this topic to QuarkusStore:

The quarkus-store-extension abstracts the use of quarkus-ignite (and quarkus-infinispan)-extension with the help of JPA/Hibernate/QuarkusStore-annotations.

[nimo23]

I come to the following conclusion:

Quarkus has already rudimentary support for Infinispan-client. Looking at Hibernate OGM, there is/was support to bind Infinispan to JPA/Hibernate. Would be great _if only that component_ will be outsourced to QuarkusStore. And if Quarkus implements an improved CacheStore for Infinispan which can be a true replacement for a typical sql database, then, I think, _there is no need and no added value to provide support for other caching technologies_ (for example, Ignite, Hazelcast, etc.).

Would be great, if Infinispan would be better integrated to the overall quarkus ecosystem (JPA/Hibernate bindings, entityManager transactions, on/off-heap storage, cold/warm caching, embeeded native mode, schema serialization support (ProtoBuf,Avro) through JPA/Hibernate/Quarkus-Mappings).

[loicmathieu]

@nimo23 when we designed MongoDB with Panache with @emmanuelbernard and @FroMage we designed it to be an example that other _database solutions_ can follow to be integrated into Quarkus _the Panache way_.

So, to me, what you describe is not Panache Store (a generic extension with multiple backend), but the need to an _Apache Ignite with Panache_.

We discuss a generic Panache extension and decided that as each database technology is very different in it's semantics (jpa is satefull / mongodb is stateless, relational vs non-relational, document oriented / column family / ...) each Panache _flavor_ needs a dedicated API. These different Panache API needs to be closed to each other but follows the semantics of the backing database.

[emmanuelbernard]

I agree with @loicmathieu, what you describe @nimo23 is more Apache Ignite with Panache. So it requires 1. to get an Apache Ignite extension to get the ignite client to work in native image, get the proper CDI injection beans etc.
Then build the Panache abstraction on top of it, like we did for MongoDB.

[nimo23]

Yes, makes sense. I think, before providing Panache Ignite, Quarkus could provide Panache Infinispan, as quarkus already supports Infinispan. It can be built on top of quarkus-infinispan and quarkus-infinispan-client. With Panache Infinispan, we can see how it solves this issue. I think, to make Infinispan work as a true replacement for a typcial sql database, there must be a dedicated Infinispan _CacheStore_ (as an equal competition to Apache Ignite Store).

Do you also think that there is a need for Panache Infinispan or/and Panache Ignite. It would be great. Actually, quarkus is super fast and the only bottleneck is the sql database which most people use because of JPA/Hibernate. As I understand, Panache Infinispan could map JPA annotated entities to Infinispan model and JPQL/Ickle to PanacheQL.

Should I create a new issue (Extension Proposal) for Panache Infinispan or Panache Ignite? Which one do you like more?

[Sanne]

Personally I like the look of such a plan, but I'm not sure if we should open extension proposals without having volunteers able and willing to try implementing it. Are you volunteering @nimo23 ?

We certainly could ask the Infinispan team, but I don't think they will have the bandwith right away. Maybe if they just had to support / mentor you it could work.

[nimo23]

without having volunteers able and willing to try implementing it

Ok, I will rename this issue and leave it open as long as someone or me is able to propose..at the moment I have not the neccessary (time) and skills to implement that by myself.

[emmanuelbernard]

Personally I like the look of such a plan, but I'm not sure if we should open extension proposals without having volunteers able and willing to try implementing it. Are you volunteering @nimo23 ?

We certainly could ask the Infinispan team, but I don't think they will have the bandwith right away. Maybe if they just had to support / mentor you it could work.

Right, if we don't have volunteers to lead that, I'd just wait.