Le 4 avr. 2018 19:37, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit :
But that's still problematic.
you have request1 ongoing and call in the following order:
ftpConfig.host();ftpConfig.port();// <- and here some config update happens
ftpConfig.username();
So even if we update the whole ftpConfig 'at once' you will end up with
mixed up information in this request, right?
The only viable solution is to have a @RequestScoped ConfigTransaction
spanning all those TypedResolvers of the whole @Configuration. At least I
could not find any better solution.
This doesnt work for at least two reasons:
1. You assume you have request scoped
2. You assume the tx has tx guarantee
The only way to have 2 is to lock the whole "current" config for the read
time (so a readwritelock for a simple impl) which makes this request scope
useless since you just need to swap the cache value and update it at once
with the lock.
LieGrue,strub
On Wednesday, 4 April 2018, 18:44:13 CEST, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:
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 <strub...@yahoo.de.invalid>:
> 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
> <strub...@yahoo.de.INVALID> 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
>
