[infinispan-dev] Calling getCache with a template and defined configuration

William Burns mudokonman at gmail.com
Mon Feb 27 09:59:41 EST 2017


On Mon, Feb 27, 2017 at 9:50 AM Radim Vansa <rvansa at redhat.com> wrote:

> While we could define the behaviour as in 3), I think that this is most
>

Yeah rereading what I wrote again, it was definitely misleading. 3) was
what I wanted when I first found the issue.


> likely a configuration error. Therefore, I'd go with 1), and ideally
>

That is what I was leaning towards as well.


> provide a link to FAQ/docs where you'd explain what exactly happened in
> the exception message.
>

Yeah I will make sure we have some stuff added to the template section of
the user guide.


>
> R.
>
> On 02/27/2017 03:31 PM, William Burns wrote:
> > When working on another project using Infinispan the code being used
> > was a bit interesting and I don't think our template configuration
> > handling was expecting it do so in such a way.
> >
> > Essentially the code defined a template for a distributed cache as
> > well as some named caches. Then whenever a cache is retrieved it would
> > pass the given name and always the distributed cache template.
> > Unfortunately with the way templates work they essentially redefine a
> > cache first so the actual cache configuration was wiped out.  In this
> > example I was able to get the code to change to using a default cache
> > instead, which is the behavior that is needed.
> >
> > The issue though at hand is whether we should allow a user to call
> > getCache in such a way. My initial thought is to have it throw some
> > sort of configuration exception when this is invoked. But there are
> > some possible options.
> >
> > 1. Throw a configuration exception not allowing a user to use a
> > template with an already defined cache. This has a slight disconnect
> > between configuration and runtime, since if a user adds a new
> > definition it could cause runtime issues.
> > 2. Log an error/warning message when this occurs. Is this enough
> > though? Still could have runtime issues that are possibly undetected.
> > 3. Merge the configurations together applying the template first.
> > This would be akin to how default cache works currently, but you would
> > get to define your default template configuration at runtime. This
> > sounded like the best option to me, but the problem is what if someone
> > calls getCache using the same cache name but a different template.
> > This could get hairy as well.
> >
> > Really thinking about the future, disconnecting the cache definition
> > and retrieval would be the best option, but we can't do that this late
> > in the game.
> >
> > What do you guys think?
> >
> >  - Will
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> 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/20170227/c30308b7/attachment.html 


More information about the infinispan-dev mailing list