Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: 24f854d) | patch
History of range tool 93/91293/1
authorTschaen, Brendan <ctschaen@att.com>
Thu, 11 Jul 2019 19:57:27 +0000 (15:57 -0400)
committerTschaen, Brendan <ctschaen@att.com>
Thu, 11 Jul 2019 19:57:27 +0000 (15:57 -0400)
commitc9bee242e27db4b20db10fcf96107b2c94e120f3
treea3ca9d2f46fe1e62afd9fcc0a5d95073f309c83etree | snapshot
parent24f854ddde6164f18ec2c7b6223befe83c583181commit | diff
History of range tool

Issue-ID: MUSIC-417
Signed-off-by: Tschaen, Brendan <ctschaen@att.com>
Change-Id: I3207d1bc38f108fb68d8760a15aafe9f0efa70ff
mdbc-server/src/main/java/org/onap/music/mdbc/ownership/OwnershipAndCheckpoint.java diff | blob | history
mdbc-server/src/main/java/org/onap/music/mdbc/tools/RangeFinder.java [new file with mode: 0644] blob
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.