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

[Dan Berindei]

I forgot to mention users can define their caches with
<distributed-cache configuration="template">...</distributed-cache> if
they want inheritance. So we don't need a way to merge configurations
at this level.


On Mon, Feb 27, 2017 at 4:52 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
> I would go for option 2.
>
> 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.
>
>
>
> 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