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

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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170227/e318eabf/attachment.html 


More information about the infinispan-dev mailing list