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. > >> 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 >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
