10:56 a.m.
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_si...
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(a)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(a)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(a)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(a)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(a)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_m...
> > >>
> > >> > 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(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev