[MDSAL-36] In-memory data store: NormalizedNode caching Created: 30/Jun/14 Updated: 04/Aug/18 Resolved: 04/Aug/18 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Description |
|
We currently do not have an API which would allow us to reuse NormalizedNode trees in the data store. This is needed for users like BGP, which contain a large number of duplicate data (for example in attributes, AS PATH, etc). Create a configurable DataStore/DataBroker decorator, which for specified (wildcard) InstanceIdentifier will maintain a Guava Cache and will transparently replace subtrees with shared versions. Also devise a way how the BGP code can specify that an instance of this decorator should be placed between its BA DataBroker and the backing BI DataStore instance. |
| Comments |
| Comment by Robert Varga [ 17/Oct/16 ] |
|
This needs to be model-driven rather than API-driven. The way this should work is that we should have a YANG language extension, which will mark subtrees as candidates for caching. Datastore implementations then can choose to perform interning when it makes sense for that implementation. |
| Comment by Robert Varga [ 04/Aug/18 ] |
|
This has been done via a caching Binding/DOM codec, which is in use by BGP for a long time now. |