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

[Thomas SEGISMONT]

Hi

2017-02-28 22:51 GMT+01:00 William Burns <mudokonman at gmail.com>:

> So while I was trying to work on this, I have to admit I am even more torn
> in regards to what to do.  Looking at [1]  it looks like the template
> should only be applied if the cache configuration is not currently
> defined.  Unfortunately it doesn't work this way and always applies this
> template to any existing configuration. So I am thinking an alternative is
> to instead make it work as the documentation states, only using the
> template if the cache is not currently defined.  This seems more logical to
> me at least.
>

I guess you started this conversation because of the issue you found in
vertx-infinispan :) Then yes, when I used this method the Javadoc made me
think that the template would be picked if no cache with the provided name
exists.


>
> With that change the getCache(String, String) could stay as long as it is
> documented that a template is only applied if no cache configuration exists.
>
> What do you guys think?
>


Sounds better to me since it's what the doc suggests.


>
> [1] https://github.com/infinispan/infinispan/blob/master/core/
> src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84
>
> On Mon, Feb 27, 2017 at 10:09 AM William Burns <mudokonman at gmail.com>
> wrote:
>
>> 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
>>
>>
> _______________________________________________
> 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/20170301/b1c35cce/attachment.html