Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(merge: 2b67ca2 c9bee24)
Merge "History of range tool" master
authorBharath Balasubramanian <bharathb@research.att.com>
Tue, 21 Jan 2020 12:11:37 +0000 (12:11 +0000)
committerGerrit Code Review <gerrit@onap.org>
Tue, 21 Jan 2020 12:11:37 +0000 (12:11 +0000)
commit9eaa82057d28fd71f63084b2a03d2a4c46c070f9
treef3827de1d7ee74a5095f41c8c8fce8a7b2e83701tree | snapshot
parent2b67ca238133bee3a4ff77cc6d0e18246f09669ecommit | diff
parentc9bee242e27db4b20db10fcf96107b2c94e120f3commit | diff
Merge "History of range tool"
mdbc-server/src/main/java/org/onap/music/mdbc/ownership/OwnershipAndCheckpoint.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.