Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: f61985d) | patch
Shutdown hook logic 07/82307/1
authorTschaen, Brendan <ctschaen@att.com>
Thu, 14 Mar 2019 21:03:27 +0000 (17:03 -0400)
committerTschaen, Brendan <ctschaen@att.com>
Thu, 14 Mar 2019 21:03:27 +0000 (17:03 -0400)
commit4bc956de441cff664657a77a609081ce154e1759
tree09bf1031de519f97d8ca634227717738181e36c7tree | snapshot
parentf61985dedb975a777bed88fb17c482d0dbb73cd8commit | diff
Shutdown hook logic

Release connections and partitions owned by this server instance

Change-Id: I293705b0d212fcba7e6f80678dee70130a8abe25
Issue-ID: MUSIC-361
Signed-off-by: Tschaen, Brendan <ctschaen@att.com>
mdbc-server/src/main/java/org/onap/music/mdbc/MdbcServer.java diff | blob | history
mdbc-server/src/main/java/org/onap/music/mdbc/StateManager.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.