Romain, your mail client is pretty broken. All my original content and your 
reply looks exactly the same.
Please try to fix your reply-to rules ;)


> This doesnt work for at least two reasons:
> 
> 1. You assume you have request scoped

Thus the fallback to native resolving in case there is no active Request 
Context. Means the current status quo.

> 2. You assume the tx has tx guarantee

No, That's where I struggle. The name 'ConfigurationTransaction' is not a DB or 
JTA transaction! It's just that you have kind of an atomic access (like in 
ACID). Look at the code, it's done via optimistic locking. It's kind of a 
transactional isolation level READ-COMMITTED, but done on a programmatic level.

> 
> 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.

That would trash our performance. And it would require to start the lock at the 
beginning of a request, and then release it at the end of a request.
Means if you would want to update some value (write-lock) then you would need 
to wait until all requests are finished (might take some seconds), BLOCK all 
new incoming requests (stand-still in the whole app) and only then you could do 
the update :(


LieGrue,
strub




> Am 04.04.2018 um 23:55 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:
> 
> 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
>> 

Reply via email to