On 09/06/18 02:06, Faseela K wrote: > [Changed the subject] > > > > Anil, now you can ask ;) > > > > https://wiki.opendaylight.org/view/Genius:Sharding_evolution >
MD-SAL long-term design: https://wiki.opendaylight.org/view/MD-SAL:Boron:Conceptual_Data_Tree Make sure to align your thinking with that... Splitting lists at MD-SAL runs into the problem of consistent hashing and scatter/gather operations: - given a key I must know which shard it belongs to (and that determination has to be *quick*) - anything crossing shards is subject to coordination, which is a *lot* less efficient than single-shard commits If it's performance you are after: - I cannot stress the importance of TransactionChains enough: if you cannot do them, you need to go back to the drawing board, as causality and shared fate *must* be properly expressed - Avoid cross-shard transactions at (pretty much) all cost. I know of *no* reason to commit to inventory and topology at the same time - if you have a use case which cannot be supported without it, please do describe it (and explain why it cannot be done) - No synchronous operations, anywhere - Producers (tx.submit() are just one side of the equation, consumers (DTCL) are equally important Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
