[controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?
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? 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
Re: [controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?
On Fri, Jul 27, 2018 at 2:30 AM Michael Vorburger 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? > > 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
Re: [controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?
On Fri, Jul 27, 2018 at 11:42 AM Anil Vishnoi wrote: > On Fri, Jul 27, 2018 at 2:30 AM Michael Vorburger > 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
Re: [controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?
On 27/07/18 13:34, Michael Vorburger wrote: > 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. I do not believe it is worth the complexity it incurs. We used to shortcut transactions which were known to have no effect and we were glad to ditch it. Regards, Robert signature.asc Description: OpenPGP digital signature ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?
On Fri, Jul 27, 2018 at 4:35 AM Michael Vorburger wrote: > On Fri, Jul 27, 2018 at 11:42 AM Anil Vishnoi > wrote: > >> On Fri, Jul 27, 2018 at 2:30 AM Michael Vorburger >> 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
