Since the cache is per instance we should just clear it on eviction at once IMHO the issue is: do you want to populate it at once too? tempted to say yes
this means it can always be active but requires to be able to copy the current config state or prevent *any* update while populating such "cache" +1 to do it without any flag Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-04-04 18:40 GMT+02:00 Mark Struberg <[email protected]>: > We should also enhance the support to include @Configuration. > e.g. if you have some class like > @Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES) > public class FtpConfigation { String host(); Integer port(); String > username(); String encryptedPwd();} > > Then you will likely resolve all those values in an atomic way. This means > that the values are basically backed by a @RequestScoped ConfigTransaction > holder. > Do we _always_ like to activate this feature?Or do we like to introduce > another flag in the @Configuration annotation? > What about threads which have no request Context active?Should it > automatically fallback to on-demand resolving? > LieGrue,strub > > On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg > <[email protected]> wrote: > > hi folks! > please review the proposed solution for DELTASPIKE-1335 > https://issues.apache.org/jira/browse/DELTASPIKE-1335 > > Not quite sure about startTransaction and ConfigTransation are the right > terms. Happy to get feedback! > > txs and LieGrue,strub >
