Transaction Chains is also useful in context of ensuring that last txn is completed before next is executed so that subsequent txn can see the changes made by previous one (of course within single subtree) more efficiently. And also enables single-writer discipline
@Robert, In context of Txn Chain, if 10 txns are submitted and failure occurs at 5th txn, the chain would provide a failure callback. Most rampant pattern part for apps would be submitting txns to the chain from DTCLs or CDTCLs. Assuming, 10 change notifications resulted in 10 chain txn submits and chain fails the 5th txn due to valid reasons, now, apps have lost the context of 5 txns which failed. In such scenarios, what would be a better approach for apps to perform any compensatory actions for failed transactions in context of using chain? Regards Muthu -----Original Message----- From: controller-dev-boun...@lists.opendaylight.org [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga Sent: Saturday, June 09, 2018 6:25 AM To: Faseela K <faseel...@ericsson.com>; Anil Vishnoi <vishnoia...@gmail.com> Cc: infrautils-...@lists.opendaylight.org; controller-dev <controller-dev@lists.opendaylight.org>; genius-...@lists.opendaylight.org Subject: Re: [controller-dev] [infrautils-dev] Sharding evolution 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 _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
