Hi Robert, >> Invalid data being written This is certainly coding error. No patch-up makes any sense here.
>> The second one stems from application design: why is the application not >> designed in a conflict - free manner Fully agree !! There is no short-cut here. There is no better first step than single-writer approach by apps who owns specific part of the data tree and adhering to that strictly across initial feature impl, enhancements / bug-fixes. Unless this foundation is there, no other patch-up(s) can be of help 'Compensatory transactions' is again the domain of applications and is orthogonal to the choice of standalone txn or chained txn as well as the type of failures Regards Muthu -----Original Message----- From: Robert Varga [mailto:n...@hq.sk] Sent: Saturday, June 09, 2018 5:37 PM To: Muthukumaran K <muthukumara...@ericsson.com>; Faseela K <faseel...@ericsson.com>; Anil Vishnoi <vishnoia...@gmail.com> Cc: infrautils-...@lists.opendaylight.org <infrautils-...@lists.opendaylight.org>; controller-dev <controller-dev@lists.opendaylight.org>; genius-...@lists.opendaylight.org <genius-...@lists.opendaylight.org> Subject: Re: [controller-dev] [infrautils-dev] Sharding evolution Hello Muthu, There are only two ways in which a transaction can fail aside from 'datastore is busted': - invalid data being written - conflicting activity outside of the causality chain The first one is an obvious coding error and I don't quite see how you'd design a recovery strategy whose complexity does not exceed complexity of the normal path. The second one stems from application design: why is the application not designed in a conflict - free manner? And when a conflict occurs, how do you know it's nature and how to reconcile it? You certainly can redo a failed transaction: it is only a matter holding on to the inputs, i.e. DTCL view is immutable. Nevertheless if it's performance you are after conflicts should happen once in a blue moon... Sent from my BlackBerry - the most secure mobile device - via the Orange Network Original Message From: muthukumara...@ericsson.com Sent: June 9, 2018 10:10 AM To: n...@hq.sk; faseel...@ericsson.com; vishnoia...@gmail.com Cc: infrautils-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; genius-...@lists.opendaylight.org Subject: RE: [controller-dev] [infrautils-dev] Sharding evolution 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
