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 <[email protected]>: > > Le 4 avr. 2018 19:37, "Mark Struberg" <[email protected]> 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 < > [email protected]> 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 <[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 >>
