[controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Michael Vorburger]

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?

[Anil Vishnoi]

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] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Robert Varga]

On 27/07/18 11:29, 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?
> 

At the very least it requires queueing, as it needs to be ordered among
transactions. Cancel is distinctly different.

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] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Michael Vorburger]

On Fri, Jul 27, 2018 at 12:21 PM Robert Varga  wrote:

> On 27/07/18 11:29, 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?
> >
>
> At the very least it requires queueing, as it needs to be ordered among
> transactions. Cancel is distinctly different.
>

but if there are no operations, it could just shortcut to cancel, no?

Would this perhaps be a worthwhile enhancement (for Neon obviously) in core
MD SAL (instead of ManagedNewTransactionRunner) ?


> Regards,
> Robert
>
>
___
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?

[Michael Vorburger]

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] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Robert Varga]

On 27/07/18 13:33, Michael Vorburger wrote:
> On Fri, Jul 27, 2018 at 12:21 PM Robert Varga  > wrote:
> 
> On 27/07/18 11:29, 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?
> >
> 
> At the very least it requires queueing, as it needs to be ordered among
> transactions. Cancel is distinctly different.
> 
> 
> but if there are no operations, it could just shortcut to cancel, no? 
> 
> Would this perhaps be a worthwhile enhancement (for Neon obviously) in
> core MD SAL (instead of ManagedNewTransactionRunner) ?

They are different operations, their outcome is different, as is their
interface contract. No, we should not be taking any shortcuts here.

Bye,
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] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Robert Varga]

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



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?

[Robert Varga]

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] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Muthukumaran K]

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: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
Sent: Friday, July 27, 2018 5:25 PM
To: Anil Vishnoi ; Michael Vorburger 

Cc: controller-dev ; 
mdsal-...@lists.opendaylight.org
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
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?

[Anil Vishnoi]

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

Re: [controller-dev] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

[Anil Vishnoi]

On Fri, Jul 27, 2018 at 4:54 AM Robert Varga  wrote:

> 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.
>
​Depends on the cost of the two operations, if cost of submitting the empty
transaction is  less than cancelling it, yes it doesn't make sense, but
otherwise i think it makes life convinient for folks directly consuming the
api (compared to through wrappers).

>
> Regards,
> Robert
>
>

-- 
Thanks
Anil
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev