[MDSAL-366] Add support for rebasing transaction in TransactionChains Created: 13/Apr/16  Updated: 20/Oct/21

Status: Confirmed
Project: mdsal
Component/s: Binding API, DOM API
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: High
Reporter: Robert Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


 Description   

InMemoryDataTree allows DataTreeModifications to be chained in a manner similar to a git branch via DataTreeSnapshot#newModification().

This means that a set of DataTreeModifications created by:

 

List<DataTreeModification> list = new ArrayList<>();
DataTreeSnapshot snap = dataTree.takeSnapshot();
for (int i = 0; i < 100; ++i) {
    DataTreeModification mod = snap.newModification;

    // ...

    mod.ready();

    list.add(mod);
    snap = mod;
}
for (DataTreeModification mod : list) {
    dataTree.commit(mod);
}

 

will observe an isolated snapshot. The problem is that maintaining the state can lean to an OOM, because a new snapshot is never taken and all those DataTreeModifications are not eligible for GC until the last modification commits.

This is problematic, as in a highly-loaded asynchronous system we may not arrive at a point where are no outstanding modifications – hence we never free the garbage.

Introduce a mechanism by which a user can request that a chain of (sealed?) DataTreeModifications can be rebased on top of a new DataTreeSnapshot. This mechanism needs to be able to fail just as DataTree.prepare() can.

 Comments   
Comment by Robert Varga [ 13/Apr/16 ]

The API should probably look like:

public interface DataTreeModification {
     DataTreeModification rebase(DataTreeSnapshot newSnapshot);
}

 and the user would do something like:

// after commiting a modification
List<DataTreeModification> outstanding;
DataTreeSnapshot snap = dataTree.takeSnapshot();
List<DataTreeModification> rebasedOutstanding = new ArrayList<>();
for (DataTreeModification mod : outstanding) {
    DataTreeModification rebased = mod.rebase(snap);
    rebasedOutstanding.add(mod);
    snap = mod;
}

 

Comment by Robert Varga [ 27/Jul/18 ]

DataTreeModification is actually ready, as it features applyToCursor(), which is not restricted to require a sealed modification. Hence the desired code snippet becomes a bit different:

 

// after commiting a modificationList<DataTreeModification> outstanding;
DataTreeSnapshot snap = dataTree.takeSnapshot();
List<CursorAwareDataTreeModification> rebasedOutstanding = new ArrayList<>();
 
for (DataTreeModification mod : outstanding) {
    DataTreeModification rebased = snap.newModification();
    try (DataTreeModificationCursor c = rebased.createCursor(YangInstanceIdentifier.EMPTY)) {
        mod.applyToCursor(c);
    }

    rebased.ready();
    rebasedOutstanding.add(rebased);
    snap = mod;
}

 

Comment by Robert Varga [ 28/Jul/18 ]

We need to expose an API for users to specify when to rebase transactions and then implement it.

Comment by Robert Varga [ 16/Mar/19 ]

Binding V2 is being removed in 4.0.0.

Generated at Wed Feb 07 20:09:37 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.