[infinispan-dev] Default cache

[Tristan Tarrant]

On 30/11/16 17:44, Paul Ferraro wrote:
> On Wed, Nov 30, 2016 at 9:13 AM, 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 ?
>
> 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 <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
> _______________________________________________
> 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