[infinispan-dev] Default cache

[Sebastian Laskawiec]

Hey Tristan,

Comments inlined.

Thanks
Sebastian

On Wed, Nov 30, 2016 at 3:13 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Some additional notes:
>
> - currently the XSD specifies the default-cache attribute on the
> cache-container element as required, but the parser doesn't enforce it.
> - A default ConfigurationBuilder is created for the default cache if one
> has not been specified
>
> My questions:
>
> 1. do we want the default cache to be optional or actually require it in
> the declarative configuration ?
>
> ** A: no enforcement. In this case requesting the default cache should
> print a warning about falling back to a "default" empty configuration.
>
> ** B: we don't require the user to specify a default cache in the
> configuration, but invoking getCache() will throw an exception.
>
> ** C: enforce it, although this will break all those XML files who
> haven't specified it.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the B approach otherwise.
>

I generally don't like the option B, since it frustrates developers and it
might make the 8.x -> 9.x migration painful.

However I really like your proposal for a GlobalConfigurationManager
with implicitCacheCreation. However I would set it to true as our default.
Effectively this would results in option A being implemented (somewhat).


>
> 2. currently, requesting a named cache for which a configuration hasn't
> been defined implicitly creates the cache by using the default
> configuration as a template.
>
> ** A: continue as is
>
> ** B: continue to implicitly create a cache, but use an empty
> configuration instead of using the default configuration, as this has
> been the source of confusion among users. Also print a warning.
>
> ** C: do not create caches unless a configuration has been explicitly
> provided.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the C approach otherwise.
>
> Unfortunately the namespace version trick doesn't work for programmatic
> configurations. Probably we should add a boolean flag on the
> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
> to false (because that's the "new order") but allows switching to the
> old behaviour if needed.
>

Again A. The same arguments as the above.


>
> In any case I'd like to also introduce a JCache-like createCache() API
>
> Tristan
>
> On 10/11/16 13:20, Paul Ferraro wrote:
> > +1000
> >
> > This is precisely how we've setup cache manager semantics in WildFly
> > (since AS7):
> > https://github.com/wildfly/wildfly/blob/master/
> clustering/infinispan/spi/src/main/java/org/wildfly/
> clustering/infinispan/spi/CacheContainer.java
> > https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/
> extension/src/main/java/org/jboss/as/clustering/infinispan/
> DefaultCacheContainer.java
> >
> > I'd love to be able to drop this.
> >
> > Paul
> >
> > On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com>
> wrote:
> >> In the discussion for [1] the subject of the default cache and the way
> >> it affects configuration inheritance came up.
> >>
> >> My proposal is:
> >> - remove the default cache as a special cache altogether
> >> - CacheManager.getCache()  should return the named cache specified as
> >> default in the configuration.
> >> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration
> should
> >> have the notion of the default named cache (currently this is handled in
> >> the parser)
> >> - Retrieving the cache named "___defaultcache" should actually retrieve
> >> the above named cache
> >>
> >> Opinions ?
> >>
> >> Tristan
> >>
> >> [1] https://github.com/infinispan/infinispan/pull/4631
> >> --
> >> Tristan Tarrant
> >> Infinispan Lead
> >> JBoss, a division of Red Hat
> >> _______________________________________________
> >> 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
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> 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/20161130/86c8daa6/attachment-0001.html