2018-04-05 9:31 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

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


RMB: not exactly since you need a workaround instead of no workaround at
all so the code path would be better without that.


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

No


> 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 :(
>


We would have:

withWriteLock(updateConfig())

and

withReadLock(updateConfigInstanceCache())

It means the overhead is null everytime except until there is a write in
the config which is the only way to guarantee the atomicity of the updates
(switch to another ftp/http/... server typically).

You can think to a lock per key*s* but it doesnt work cause we support
placeholding and this means you must lock the whole config to impl it.

This impl is good in terms of perf since the updates will not be that
frequent. If you care of that small "stop the world' - but keep it mind it
should be very small - then we can use a queue to update the data so the
write fills a queue (or just a flag) which once in the right state will
force the consumers (config instances) to reevaluate the current values.
The issue here is that you still need to lock the world to copy the config
state (you cant assume it is scannable in most of the cases) to stay atomic.

Long story short: there is no real choice if you want to be atomic
transparently (ie without adding a relationship between keys + keep in the
instance this relationship to know what to update when there is a write
which goes to the placeholding replacements).
To already have use RW for that I don't see it as a perf blocker.

What about trying and measure it?





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