On Fri, Jul 27, 2018 at 4:35 AM Michael Vorburger <vorbur...@redhat.com> wrote:
> On Fri, Jul 27, 2018 at 11:42 AM Anil Vishnoi <vishnoia...@gmail.com> > wrote: > >> On Fri, Jul 27, 2018 at 2:30 AM Michael Vorburger <vorbur...@redhat.com> >> wrote: >> >>> Hello, Tom, Robert, Stephen, >>> >>> Does commiting a transaction with no put/.../merge/delete operations on >>> that Tx have any noteworthy (real life) overhead compared to cancelling it? >>> >>> I am asking because that has come up in >>> >>> https://git.opendaylight.org/gerrit/#/c/74506/1/lockmanager/lockmanager-impl/src/main/java/org/opendaylight/genius/lockmanager/impl/LockManagerServiceImpl.java@a229 >>> and I was wondering if there is any point in making our >>> ManagedNewTransactionRunner "smarter" so that it does a cancel if it wasn't >>> actually used. >>> >>> 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? >> > > we would not even need an isEmpty() to be able to do such an optimization > in our ManagedNewTransactionRunner, we could track it ourselves. What I > am wondering if such a short cut optimization has any real value, and if it > does if it shouldn't go into core MD SAL instead of > ManagedNewTransactionRunner. > Not everybody is using ManagedNewTransactionRunner, so whoever is using the API's directly they need to do the tracking anyways. To me is seems like you are adding elements to array, but keeping the counter out side of the array, rather than asking List contact to say whether it's empty or not. > > >> >>> Tx, >>> M. >>> -- >>> Michael Vorburger, Red Hat >>> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = >>> http://vorburger.ch >>> _______________________________________________ >>> controller-dev mailing list >>> controller-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>> >> >> >> -- >> Thanks >> Anil >> > -- Thanks Anil
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
