...
http://ec-wacs.adobeconnect.com/openncp/
Room Passcode: markus.kalliola or michele.foucart
------------------------------------------------------------------------------------------------
If you have never attended an Adobe Connect meeting before:
Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm
Get a quick overview: http://www.adobe.com/products/adobeconnect.html
Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
------------------------------------------------------------------------------------------------
Participants
S
Joao Cunha
Kostas Karkaletsis
Massimiliano Masi
Marcello Melgara
YacoubouY
michele.foucart
Support documents
https://openncp.atlassian.net/wiki/pages/viewpage.action?spaceKey=ncp&title=Cache+implementation+through+ConfigurationManager+refactoring
View file |
---|
name | Change_Proposal-Caching-Mechanism-V0 2 - .pdf |
---|
height | 250 |
---|
|
Meeting Notes
Introduction, context
S explains the solution proposed
Advantages, impacts...
Massimiliano Masi:
- change proposal is supposed to be used for change of specs, based on objective results. So challenging objective
- From a technical point of view, the best solution
- Results of EC tests not share on Confluence, missing measures
Is this a change? Distinction between software bugs, change of specs, or improvement of something existing
Marcello Melgara: any change must converge to something that is stable and useful for MS. For every change it must reach an agreement, if agreement not reach we need to escalate.
Massimiliano Masi: question of complexity:
- product useful for MS
- We don't know yet the size (how many messages, patients, documents...), so we should do the best
- Reality for CEF:
- 21 countries applied
- 1 million EU citizens...
- Results? We don't know because not a comparison of the same thing
- Impact? 1/2 day effort for the CP.
- Not sure, because keeping the DB and...more complex than the other solutions
- S: 3 or 4 calls to the db, simple hashmap.
- Get properties to the conf manager is called every time, should be one of the top priority
- Keep the value in memory as long as it changes
- With DB approach (micro cache), use DB every time the cache is expired => DH hit more often than we think
- The solutions should be compared
- The idea of what we want to use // Redis
- More complex + does not help SMP/SML:
- Process: change end point once a year...
- Micro caching: good but
- Publish subscriber (e.g. Redis): 1 SMP call against 2 uses cases, 5 lines of code
- Each cache in hibernate or also microcache? Idea was to use both (IH? Hibernate? cache + micro cache) => not clear in the proposal
- context of the properties which won't change som much, so even if refresh once start day, 1 call to the database? => to be completed
- Tests microcache: