[infinispan-dev] Obtaining cache via CDI on WildFly

Wolf Fink wfink at redhat.com
Thu Dec 6 07:45:43 EST 2018 

As far as I know the latest 6.4 and 7.x

On Thu, Dec 6, 2018 at 12:58 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Yes, that's a good point. That's why we add the targeted WF version to
> the id of the HV patch files (in general we try to only have one for
> the latest WF at that point in time). A plain ZIP is more forgiving in
> that regard, although I'd argue it should be tested and documented
> which server versions are supported by a given ZIP (e.g. this wasn't
> quite clear to me from the Infinispan docs).
> Am Do., 6. Dez. 2018 um 11:05 Uhr schrieb Wolf Fink <wfink at redhat.com>:
> >
> > As the DG modules are for EAP6 and EAP7 there is no simple way to have
> one zip for all releases. This means we have to multiply the zip if use
> that approach and add more testing.
> >
> > On Thu, Dec 6, 2018 at 10:56 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Hi,
> >>
> >> So I'm using the module ZIP now and changed my app to depend on that
> >> specific slot. Works nicely, thanks again.
> >>
> >> One quick note on the module ZIP: this adds modules to the server's
> >> original "system" directory, so this can be tough to be undone, if
> >> needed (not so much an issue when thinking of containerized immutable
> >> infra, but the more traditional server admin might be more concerned).
> >> Have you considered to provide a file using the server's patching
> >> mechanism instead? It's still a ZIP essentially, but contains some
> >> additional metadata. By applying this via jboss-cli.sh's patch
> >> command, this can cleanly be undone (the contents are put into a
> >> separate "overlays" directory instead of "system" itself).
> >>
> >> As an example, Hibernate Validator is providing a patch based on that
> approach:
> >>
> >>
> https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_updating_hibernate_validator_in_wildfly
> >>
> >> We've also developed a Maven plug-in which helps to produce such patch
> >> file. You can see it in use for HV here:
> >>
> >>
> https://github.com/hibernate/hibernate-validator/blob/master/modules/pom.xml
> >>
> >> --Gunnar
> >>
> >> Am Mi., 5. Dez. 2018 um 17:01 Uhr schrieb Gunnar Morling <
> gunnar at hibernate.org>:
> >> >
> >> > > if all you want is to invalidate Hibernate ORM's 2LC caches,
> Hibernate
> >> > > exposes a specific API to do just that.
> >> >
> >> > Yes, I am aware of this (using the JPA method for that in the blog
> post).
> >> >
> >> > But I only want to invalidate the caches after external transactions,
> >> > i.e. not after transactions run by the app and Hibernate itself. Hence
> >> > I'm keeping a cache of transaction ids run by the application, so the
> >> > Debezium event handler can match incoming change events against them
> >> > and only call evict() after transactions _not_ executed by the
> >> > application. It's described in the blog post draft I linked, perhaps
> >> > you can take a look and let me know in case I'm missing anything?
> >> > Thanks!
> >> >
> >> >
> >> > Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero
> >> > <sanne at infinispan.org>:
> >> > >
> >> > > Hi Gunnar,
> >> > >
> >> > > if all you want is to invalidate Hibernate ORM's 2LC caches,
> Hibernate
> >> > > exposes a specific API to do just that.
> >> > >
> >> > > Sanne
> >> > >
> >> > > On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > > >
> >> > > > Hey all,
> >> > > >
> >> > > > Thanks a lot for the quick replies!
> >> > > >
> >> > > > To give some background on what I was trying to do: my intention
> was
> >> > > > to use a simple cache within my app for a demo + blog post I'm
> >> > > > creating on invalidating the JPA 2nd-level cache after external
> data
> >> > > > changes (i.e. bypassing the app) via Debezium:
> >> > > >
> >> > > >
> https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
> >> > > >     https://github.com/debezium/debezium.github.io/pull/230
> >> > > >
> >> > > > For that I need a simple in-app cache to keep track of all
> >> > > > transactions run by the app itself, so to keep them apart from
> >> > > > transactions run by external clients (as I need to invalidate the
> 2L
> >> > > > cache items only for the latter).
> >> > > >
> >> > > > So the questions around support are not too much of a concern for
> my
> >> > > > purpose. Using the modules coming with the server seemed so easy
> in
> >> > > > comparison to putting the modules in place :) I'll try and have a
> look
> >> > > > at how this could be done in my Dockerfile (this btw. could be an
> >> > > > interesting example for you to have, too). Regarding CDI, I gave
> up on
> >> > > > this and just obtained a cache via the API. Seemed simpler in the
> end.
> >> > > >
> >> > > > Thanks again,
> >> > > >
> >> > > > --Gunnar
> >> > > >
> >> > > >
> >> > > > Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <
> wfink at redhat.com>:
> >> > > > >
> >> > > > > As Tristan said, the infinispan bits shipped with WildFly and
> its configuration will not have all ISPN features. It might change over the
> time as there is no test which ensure that any feature beside those which
> are used from the WF container.
> >> > > > > The configuration for the subsystem is different and will not
> allow all features.
> >> > > > > Also if there is a plan to move to the supported products this
> is not supported!
> >> > > > >
> >> > > > > The best option is to use the infinispan modules and configure
> it in server-mode, in this case the cache lifecycle is bound to the WF
> instance and can be shared/injected to all deployed applications (sharing
> the cache between application in embedded mode will not work)
> >> > > > > Note that you might use the infinispan endpoints here, but if
> there is a plan to use the products the use of endpoints is not supported
> (as it will make WF a hybrid server for both)
> >> > > > >
> >> > > > > Wolf
> >> > > > >
> >> > > > > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <
> ttarrant at redhat.com> wrote:
> >> > > > >>
> >> > > > >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> >> > > > >> > Hey,
> >> > > > >> >
> >> > > > >> > I was trying to configure and inject an Infinispan cache
> through CDI,
> >> > > > >> > running on WildFly 14, using the Infinispan modules provided
> by the
> >> > > > >> > server.
> >> > > > >> >
> >> > > > >> > While I'm not sure whether that's something supported or
> recommended,
> >> > > > >> > I found this preferable over adding Infinispan another time
> as part of
> >> > > > >> > the deployment. I couldn't find any recent info on doing
> this (would
> >> > > > >> > love any pointers, though), so here's my findings, in case
> it's
> >> > > > >> > interesting for others:
> >> > > > >>
> >> > > > >> You should not be using the Infinispan subsystem that comes
> with WildFly
> >> > > > >> as its configuration capabilities are a bit limited, but the
> modules we
> >> > > > >> supply:
> >> > > > >>
> >> > > > >>
> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
> >> > > > >>
> >> > > > >> > Btw. I also couldn't find an example for configuring a cache
> through
> >> > > > >> > jboss-cli.sh, perhaps that's something to consider, too?
> >> > > > >>
> >> > > > >> Yes, that should be added.
> >> > > > >>
> >> > > > >> Tristan
> >> > > > >> _______________________________________________
> >> > > > >> infinispan-dev mailing list
> >> > > > >> infinispan-dev at lists.jboss.org
> >> > > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > > >
> >> > > > _______________________________________________
> >> > > > infinispan-dev mailing list
> >> > > > infinispan-dev at lists.jboss.org
> >> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181206/5a72ff72/attachment.html

More information about the infinispan-dev mailing list