[jira] [Comment Edited] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082350#comment-16082350
]
Alexander Falb edited comment on DELTASPIKE-1277 at 7/11/17 3:09 PM:
-
(Uploaded central_caching.patch)
This is a first try of how a central cache could work. It is far from perfect,
because of the dynamic nature of cache-keys containing projectstage and/or
parameters. There are at least a dozen of unit tests missing covering all sorts
of loading a projectstaged/parameterized keys, caching it, changing the other
value, reloading it and so on, but I think this could be a start at least.
What do you think?
was (Author: elexx):
This is a first try of how a central cache could work. It is far from perfect,
because of the dynamic nature of cache-keys containing projectstage and/or
parameters. There are at least a dozen of unit tests missing covering all sorts
of loading a projectstaged/parameterized keys, caching it, changing the other
value, reloading it and so on, but I think this could be a start at least.
What do you think?
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb updated DELTASPIKE-1277:
---
Attachment: central_caching.patch
This is a first try of how a central cache could work. It is far from perfect,
because of the dynamic nature of cache-keys containing projectstage and/or
parameters. There are at least a dozen of unit tests missing covering all sorts
of loading a projectstaged/parameterized keys, caching it, changing the other
value, reloading it and so on, but I think this could be a start at least.
What do you think?
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082443#comment-16082443
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Really looks close to what I have in mind. I have however some questions after
the patch review (some unclear area):
- if not using caching do we still "cache" in the shared cache? If not we can
try to do it I think otherwise if you read twice the same key the behavior is
now different from what it is today (you can get a corrupted data)
- any reason to not move to a ConfigContext and add another Map (tried to write
it in previous comment but re-reading it was maybe not clear): I think it would
be beneficial to store all config contextual (per classloader) data in a single
structure (I called it ConfigContext but any other name is good). It would
allow to have all the data you can need in all related places and avoid to
clear cache in config source method for instance ;)
Once these small tech-y details "fixed"/"discussed" I'd like to have a small
iteration on the API. Maybe having a "ConfigCacheManager" can be beneficial
instead of polluting the ConfigResolver itself (even if it delegates, it is
purely in term of API here) and we should surely embrace more java 8 - just
providing functional interface but not having any strong adherance):
{code}
// surely added as a bean but also accessible from the ConfigContext for
extensions?
public interface ConfigCacheLManager {
void clear();
void remove(String key);
void removeIf(BiPredicate predicate); // for all cached
values, if the predicate matches then remove
}
{code}
Nice thing about the removeIf is it allows to manage easily
(startsWith/endsWith) groups of keys (startsWith("app.database.")).
Hope it makes sense
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
