Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(merge: 84c322b 42214c8)
Merge "Replay Transaction Updates"
authorBharath Balasubramanian <bharathb@research.att.com>
Wed, 4 Sep 2019 15:45:00 +0000 (15:45 +0000)
committerGerrit Code Review <gerrit@onap.org>
Wed, 4 Sep 2019 15:45:00 +0000 (15:45 +0000)
commitd2b5c18e008c4be333ff0f5c47d1d8136802f6b6
treed687a5bb030ff0246522c116991a14f51f6874cbtree | snapshot
parent84c322b7d05bb820af38421fbda75e8dc9817c69commit | diff
parent42214c84ef398fb65db4d84012de1e46c585f300commit | diff
Merge "Replay Transaction Updates"
mdbc-server/src/main/java/org/onap/music/mdbc/StateManager.java diff1 | diff2 | 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.