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

[William Burns]

On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei <dan.berindei at gmail.com> wrote:

> I would go for option 2.
>

Do you think a WARN message will be enough? I am a bit weary about this
option myself.


>
> We already started disconnecting the cache definition and retrieval,
> at least `getCache(name)` doesn't define a new cache based on the
> default configuration any more. So I don't think it would be too much,
> even at this point, to deprecate all the overloads of `getCache` that
> can define a new cache and advise users to use `defineConfiguration`
> instead.
>

Hrmm I like the idea of deprecating the overloads :)


>
>
>
> Cheers
> Dan
>
>
> On Mon, Feb 27, 2017 at 4:31 PM, William Burns <mudokonman at gmail.com>
> 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
> _______________________________________________
> 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/47249079/attachment-0001.html