> 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
<sa...@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 <gun...@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 <wf...@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 <ttarr...@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@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to