Hi Robert, Slightly orthogonal question delving more into overheads
Would the overhead not be higher than just trivially marginal on the backend for a transaction ? In other words, the moment newXYZTransaction is created, proxy, context, snapshot, txn-actors and other related objects get initiated at the backend - is it not ? And an empty Op list of transaction is inferred only during submit call and all of above initializations will straight away be garbaged right ? If the "NOOP" type txn count is far lesser, then the pressure of such garbage would not be higher but OTOH, if this NOOP txn semantics is misused, their count could become humongous and hence corresponding unnecessary garbage and subsequent collection cycles - is it not ? Am I missing something in context of laziness / eagerness with which all backend objects (heavy / light) created in context of each txn ? Regards Muthu -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Varga Sent: Friday, July 27, 2018 5:25 PM To: Anil Vishnoi <[email protected]>; Michael Vorburger <[email protected]> Cc: controller-dev <[email protected]>; [email protected] Subject: Re: [controller-dev] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it? On 27/07/18 11:41, Anil Vishnoi wrote: > > My initial reaction is that such an optimization in > ManagedNewTransactionRunner is probably pointless as whatever > happens behind the scenes on a commit is surely already smart enough > by itself for a submit on an empty transaction to basically be a low > overhead NOOP anyway? > > Or if transaction API can expose some api like isEmpty() (just > example), that can come bit handy here? I don't think the benefit of such a method justifies additional state tracking required to support it. Regards, Robert _______________________________________________ controller-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/controller-dev
