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. ------------------------------------------------------------------------------------------------
Idea was on Friday SMP/SML meeting to agree on solution proposed by the DSI owner.
Solution chosen by the eHDSI SP because limited impact on code, effort etc.
But impact was challenged during the SMP/SML meeting, reason of the tenue of this meeting
S explains the solution proposed, its advantages, impacts...
Solution proposed is "enough" for our needs
static data that do not change and end points that change once every 6 months
Redis gives better results but maybe not necessary needed for our needs (get 60 properties...)
Limited impact on code/effort: 1 additional class or 1 annotation, 1/2 day development
No new installation/configuration needed
"Effort" is the key reason for this choice since we don't have resources available now for this, the project has already other priorities (SMP/SML, Terminology...)...
change proposal is supposed to be used for change of specs, based on objective results. So challenging objective
Is this a change? Distinction between software bugs, change of specs, or improvement of something existing
From a technical point of view, the publisher subscriber system will lead to better performance
Missing measures from the CP, solution should be documented/shared on Confluence
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.
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
Question from Joao Cunha: 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 so much, so even if refresh once start day, 1 call to the database...
Tests microcache
The solutions should be compared
Next steps:
Proposition to add a dimension in the table of conclusion, which is "effort", and also 2 lines with the KEY advantages and disadvantages of each solution
The solution described in the CP will be published in Confluence (including updates following today's meeting, additional info...) and share tests results
Organise a new meeting to make a new status on this topic