Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: 361533f) | patch
Optimize eventual reads 58/84358/1
authorstatta <statta@research.att.com>
Fri, 5 Apr 2019 14:54:06 +0000 (10:54 -0400)
committerstatta <statta@research.att.com>
Fri, 5 Apr 2019 14:54:29 +0000 (10:54 -0400)
commit8ee3c10928c025c3908ce60314c40dd22755e544
tree4692acecb9392d5ebfb34fd7748184739351009ftree | snapshot
parent361533ff29d77c78a418967229e9fc6d72d46bd6commit | diff
Optimize eventual reads

Issue-ID: MUSIC-371
Change-Id: Ica2a27a16dd82e5c99cb5775d39c6526ed086187
Signed-off-by: statta <statta@research.att.com>
mdbc-server/src/main/java/org/onap/music/mdbc/mixins/MusicMixin.java diff | blob | history
mdbc-server/src/main/java/org/onap/music/mdbc/tables/StagingTable.java diff | blob | history
mdbc-server/src/test/java/org/onap/music/mdbc/mixins/MusicMixinTest.java diff | blob | history
The most crucial recipe is a multi-site database cache (mdbc) that enable ONAP components that maintain state in a SQL database to avail the benefits of MUSIC without compromising their need to use transactional SQL DBs. These ONAP components can rely on existing db clustering techniques like MariaDB for transactionality and complex querying within a site. mdbc will intercept each of these read/write calls to the db cluster and mirror this state to other geo-distributed sites through MUSIC either synchronously or asynchronously (configurable at a table-level). For example, components like the ONAP Service Orchestrator that use MariaDB to maintain state can directly use this recipe with no change to their SQL code.