[infinispan-dev] Default cache

[Paul Ferraro]

On Wed, Nov 30, 2016 at 12:41 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> 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.

Yes - and this was one of my biggest complaints about this API.  There
ought to be a distinction between "managed" caches vs. "ad hoc"
caches.  This (along with the class loading mess) is one of the
reasons why this spec isn't ready for the EE world.

>>> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev