Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: 361533f) | patch
Close connection also updates StateManager 02/84402/2
authorArthur Martella <arthur.martella.1@att.com>
Fri, 5 Apr 2019 21:13:52 +0000 (17:13 -0400)
committerArthur Martella <arthur.martella.1@att.com>
Mon, 8 Apr 2019 16:54:04 +0000 (12:54 -0400)
commit3d19f1656446b9095750de7a87aaca08e95cdeda
tree5e745a35a21a0077df7bbda12414598c84689701tree | snapshot
parent361533ff29d77c78a418967229e9fc6d72d46bd6commit | diff
Close connection also updates StateManager

Change-Id: I5861e06a5d11e8bf58a5ae5c470cc62e1861b77f
Issue-ID: MUSIC-369
Signed-off-by: Arthur Martella <arthur.martella.1@att.com>
mdbc-server/src/main/java/org/onap/music/mdbc/MdbcConnection.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.