1. Infinispan based MD-SAL Data 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 ISPN Mgmt 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
TreeCache RemoveNode 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