Quantcast

[infinispan-dev] Default cache

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Default cache

Tristan Tarrant-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Sanne Grinovero-3

I like it: it makes the existence and the name of the default cache explicit to the user, with no practical drawbacks.

Thanks,
Sanne


On 10 November 2016 at 08:38, Tristan Tarrant <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Paul Ferraro
In reply to this post by Tristan Tarrant-2
+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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Tristan Tarrant-2
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.

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.

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

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Sebastian Laskawiec
Hey Tristan,

Comments inlined.

Thanks
Sebastian

On Wed, Nov 30, 2016 at 3:13 PM, Tristan Tarrant <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Paul Ferraro
In reply to this post by Tristan Tarrant-2
On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <[hidden email]> 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).

> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Tristan Tarrant-2
On 30/11/16 17:44, Paul Ferraro wrote:

> On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Paul Ferraro
On Wed, Nov 30, 2016 at 12:41 PM, Tristan Tarrant <[hidden email]> wrote:

> On 30/11/16 17:44, Paul Ferraro wrote:
>> On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <[hidden email]> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Tristan Tarrant-2
In reply to this post by Sebastian Laskawiec
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> 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
>     >> [hidden email]
>     <mailto:[hidden email]>
>     >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Default cache

Galder Zamarreño
There is a valid point to Paul's suggestion:

Caches created via createCache() should be managed by the app itself, which would make it more symmetrical. It'd  be asymmetrical for a cache created by the user code to be managed by the server itself. If you create something, you should destroy it yourself.

However, we can't really change the behaviour of getCache() to not return caches created via createCache(). If we did that in the JCache impl, we'd break the API. We could have JCache impl adhere to that, but have Infinispan getCache() behave the way Paul suggests. Since we would be adding createCache() for the first time to Infinispan Cache, in theory we're free to define how to deal with caches created via createCache() the way we want. That we'd deviate from JCache would be unfortunate but the right thing.

Thoughts?
--
Galder Zamarreño
Infinispan, Red Hat

> On 1 Dec 2016, at 08:30, Tristan Tarrant <[hidden email]> wrote:
>
> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>    <[hidden email] <mailto:[hidden email]>> 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
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>    <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> 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
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>    <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...