On 30/11/16 17:44, Paul Ferraro wrote: > On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarr...@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 ? > > In WildFly, default-cache has been optional since WF8. The > cache-container used for hibernate 2LC, for example, does not have any > concept of a default-cache. So, for us anyway, it makes sense for > default-cache to be optional. However, we have the luxury of falling > back to Infinispan's default getCache() logic in the event that no > default-cache was specified. > >> ** 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 think that makes sense. > >> 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. > > Agreed. > >> 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. >> >> In any case I'd like to also introduce a JCache-like createCache() API > > I think it would be best/cleanest if caches created via this API are > anonymous (i.e. not managed by the cache manager or made accessible > via getCache(String)). That way there is no ambiguity about who is > meant to manage the lifecycle (user vs container).
Hmm, this differs from the behaviour of JCache's getCache(String) though. > >> 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 <ttarr...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
