Between the 3 createSnapshot or snapshot.
What about ImmutableConfig and Config.toImmutable(keys)?
Not a big deal though.
Le 5 avr. 2018 21:38, "Thomas Andraschko" <andraschko.tho...@gmail.com> a
écrit :
+1 for ConfigSnapshot and Config#snapshot
2018-04-05 21:32 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> Had a long discussion with Tomas Langer about atomic access this
afternoon.
>
> What we came up with is probably better than 'ConfigTransaction', because
> the 'Transaction' term really creates the wrong impression.
>
> So what about
>
> * renaming ConfigTransaction to ConfigSnapshot and
> * Config#createTransation to
> - Config#resolveSnapshot or
> - Config#createSnapshot, or just
> - Config#snapshot ?
>
> Any thoughts? Or even any better ideas?
>
> txs and LieGrue,
> strub
>
> > Am 05.04.2018 um 10:39 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Yes, you are right, in all cases the source must send an event to the
> > aggregator (config) to notify it to update its state (timestamp or not).
> > Thought we could support it transparently but seems there always have
> > border cases in advanced impl we sadly often rely on in prod ;).
> > It cant be a config access directly but we can add an update event for
> that
> > (if we dont want a cdi event we can allow sources to implement Updatable
> {
> > void afterUpdate(Collection<String> keys) } probably which would do the
> > relationship without having a real cycle on the code)
> >
> >
> >
> > 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-05 10:30 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >
> >> But the writeLock would need to be performed by the ConfigSources.
> >> So we need to change them anyway.
> >>
> >> In the current solution any ConfigSource which performans an update
> would
> >> just need to call the reportAttributeChange callback.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 05.04.2018 um 09:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 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
> >>
> >>
>
>
