Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: 65b45ca) | patch
Include connection info in log 18/89718/1
authorTschaen, Brendan <ctschaen@att.com>
Tue, 11 Jun 2019 18:26:58 +0000 (14:26 -0400)
committerTschaen, Brendan <ctschaen@att.com>
Tue, 11 Jun 2019 18:26:58 +0000 (14:26 -0400)
commitac3c3123a7d660d85bdcbc013e63b439b430ec42
tree7c09d1f685cc6b5a557ce805e1c6b9e9bd2156e9tree | snapshot
parent65b45cafb4dff93bef52e91f2ab3f2a772e4472ecommit | diff
Include connection info in log

Issue-ID: MUSIC-409
Signed-off-by: Tschaen, Brendan <ctschaen@att.com>
Change-Id: I4d84d7cbc407f314f22b7a659dc499b23375c470
mdbc-server/src/main/java/org/onap/music/mdbc/MdbcServerLogic.java diff | blob | history
mdbc-server/src/main/resources/logback.xml 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.