Infinispan based MD-SAL Data Store POC

1. Infinispan based MD-SALData Store POC

2. Goals • Validate the Data Store SPI by plugging an alternate implementation • Gain experience with MD-SAL Internals • Measure the overhead incurred by encode/decode when NormalizedNode is NOT the native format for the store • Provide a Data Point for comparison

3. Architecture DataStore Impl Encode/Decode Txn Mgmt ISPN TreeCache Change Notifications

4. Implementation Notes • Mapping to Tree Cache API • InstanceIdentier of Parent -> Tree Cache Node FQN • InstanceIdentifier of LeafNode/LeafSetEntryNode ->Map Key • LeafNode/LeafSetEntryNode Value->Map Value • Data Store Transaction mapped to TreeCache JTA Transaction • DataChange Notifications • Take a NormalizedNode Snapshot at beginning of Txn • Maintain a Transaction Log • Prepare ChangeEvents during Pre-Commit • Asynchronously send change events after commit

5. Learnings • Mapping Data Store Transactions to ISPN JTA Transactions • Read Only Transactions may not get closed • Write and Delete methods in read-write transaction do not return a future • Data change events can be VERY expensive for anything but the In Memory store • Mapping to and from NormalizedNode can get complicated • TreeCacheRemoveNode API does not work reliably

6. Mapping Datastore Transactions • Data Store supports multiple transactions per thread • JTA supports only one active transaction per thread • Transactions will need to be suspended/resumed appropriately • Suggestion • Allow only one active transaction per thread • Add an explicit suspend/resume method on a transaction

7. Closing Read-only Transactions • For In-Memory Transactions, NOT closing a Read-Only Transaction is not an issue. It would be garbage collected • For JTA Transactions supported by other persistent data stores this may cause issues • Suggestion • Document that transaction close is mandatory for Read-Only Transactions as well

8. Write and Delete methods without Future • Write and Delete methods on DOMWriteTransactions return a void giving the impression that they are synchronous • Synchronous implementation may not be always possible • Suggestion • Return a ListenableFuture for Write and Delete for consistency

9. DataChange events • DataChange events require old and new data subtrees to be returned • Since the scope of the transactions is not known in advance, Entire data tree snap-shot has to be preserved • Tree snap-shot is trivial for in-memory store but could be VERY expensive for alternate implementations • Suggestion • Validate the use cases for returning entire sub-tree • Implementation must implement MVCC to support efficient data change notifications

10. Mapping to NormalizedNode • For the In-Memory Store, NormalizedNode is the native format • For any alternate implementation, NormalizedNodes have to be constructed from native formats like SQL, K-V Store or Document store • Suggestion: • Provide utility classes to map NormalizedNodes to/from a simple tree structure

11. State of POC • Fully functional. Not well tested • Integrated with the controller. • With Data Change Events performance is HORRIBLE • Without Data Change Events, performs same or better than the In Memory Data Store • Potential Optimization: Leverage ISPN MVCC or eliminate tree snap-shot at beginning and apply use Txn log to derive original • Seems to perform more consistently than the In Memory data store which slowly degrades over time • Next Steps: • No plans to pursue an Infinispan implementation at the moment. • Incorporate the learnings into data store design for Helium