I think those interfaces are already in place - at some extent. We have a
few different db implementations already: mongo, Postgres, rocksdb; so I’d
suspect that it should be enough for now.

I also would argue that H2 is also a reasonable solution for in-memory with
low cost and is now actively used in jBPM when running in dev mode.

-
Alex

On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <gabriele.card...@gmail.com>
wrote:

> HI Alex,
> I agree with your concern.
> I do not know exactly where and why infinispan is used, but I also hit
> issues with it during some upgrades.
> From my POV the issue is that
> 1. On one side, we want to provide in-memory support for our applications,
> which is a good feature
> 2. on the other side, we implemented specific solutions, with hard-binding
> to that specific implementation (infinispan), that lead to the issue you
> mentioned
>
> Being everything open source, maybe a good solution would be to design and
> provide API/interfaces for any "in-memory" database, and then whoever wants
> to create a specific implementation, outside our apache-kie project, would
> still be able to create it.
>
> Wdyt ?
>
> Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <porce...@apache.org
> >
> ha scritto:
>
> > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> version,
> > we’re currently dealing with the impact of aligning with Infinispan 15,
> > which introduces a new set of changes and potentially api compatibility
> > issues.
> >
> > Given this context, I’d like to revisit the question: Do we really want
> to
> > continue supporting Infinispan?
> >
> > This has been discussed in the past, and there was some resistance to
> > removing it. However, maintaining support goes beyond the existing
> > implementation—it requires us to stay on top of future upgrades, adapt to
> > API changes, and deal with potential security vulnerabilities stemming
> from
> > Infinispan itself and its transitive dependencies.
> >
> > I believe it’s worth re-evaluating its value and whether it’s aligned
> with
> > the future direction of the project.
> >
> > Looking forward to your thoughts.
> >
> > -
> >
> > Alex
> >
>

Reply via email to