Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: 37f5ca0) | patch
End test with a select all 44/91944/2
authorTschaen, Brendan <ctschaen@att.com>
Wed, 24 Jul 2019 13:43:23 +0000 (09:43 -0400)
committerTschaen, Brendan <ctschaen@att.com>
Thu, 25 Jul 2019 18:20:50 +0000 (14:20 -0400)
commit394d23b48b5baffe02230e47ff3479c913cf9b55
treed245332e0446de19b27d5ebf1ac7eba31e82ff02tree | snapshot
parent37f5ca0aa6f950b77da6acbeed5c9ae7069c3d6ecommit | diff
End test with a select all

Issue-ID: MUSIC-420
Signed-off-by: Tschaen, Brendan <ctschaen@att.com>
Change-Id: I8abb83b81fbbf976842f244111eb939d7e077152
mdbc-server/src/main/java/org/onap/music/mdbc/examples/MdbcTestMultiClient.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.