[infinispan-dev] Default cache

Tristan Tarrant ttarrant at redhat.com
Thu Dec 1 02:30:09 EST 2016


If we go with your approach, there would be little incentive for users 
to actually fix their application. The problem here is that the 
"inheritance from the default cache" anti-feature is more often than not 
the cause of misunderstanding. The real fix is to use configuration 
templates, obviously.

Tristan

On 30/11/16 16:24, Sebastian Laskawiec wrote:
> Hey Tristan,
>
> Comments inlined.
>
> Thanks
> Sebastian
>
> On Wed, Nov 30, 2016 at 3:13 PM, Tristan Tarrant <ttarrant at redhat.com
> <mailto: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/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
>     <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 <mailto: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
>     <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
>     <mailto:infinispan-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <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 <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <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


More information about the infinispan-dev mailing list