Uploaded image for project: 'mdsal'
  1. mdsal
  2. MDSAL-848

Add support for compacting InMemoryDataTree

XMLWordPrintable

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Medium Medium
    • 14.0.0
    • None
    • Binding API, DOM API, IMDS

      InMemoryDataTree is using MVCC to reconcile individual transactions.

      This means that we maintain significant state tracking for each component (containers, lists, list entries and all the way down to individual leaves) based on how these have been introduced.

      There are application access patterns which use a burst of transactions on a particular subtree, but once that burst is completed, they subtree is considered complete and will not modified until the next burst occurs.

      In such a scenario the application would like to coalesce the metadata, so that the entire subtree looks as if it was created with a single write() operation. This is already possible to issue such a transaction with current DataTree APIs.

      Unfortunately this is less then efficient with MD-SAL APIs when remoting is in the picture, as is the case with sal-distributed-datastore – which requires entire data to be transferred to the frontend and then back to the backend. Futhermore such an overwrite ends up being completely journalled through sal-akka-raft.

      Consider designing a compact() method (and its Binding equivalent), available as an extension to DOMDataBroker, something like the atomic equivalent of:

      public FluentFuture<? extends CommitInfo> compact(LogicalDatastoreType datastore, YangInstanceIdentifier path) {
          final var tx = newReadWriteTransaction();
          final var data = tx.read(datastore, path).get();
          if (data.isPresent()) {
              tx.put(datastore, path, data.orElseThrow());
          }
          return tx.commit();
      }
      

      Note this also needs to be available as a DOMTransactionChain operation and it needs to be actually implemented in the concrete mdsal.dom.spi.DOMStore, so that implementations have complete visibility as to what is going on. That is important for sal-distributed-datastore, as there the journal footprint should essentially be just the path being compacted.

            Unassigned Unassigned
            rovarga Robert Varga
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: