| Message ID | 20190422210024.13848-1-blp@ovn.org |
|---|---|
| State | Accepted |
| Commit | c15a5dcf575fb0e3790759e79eb68fcedf45b8c4 |
| Headers | show |
| Series | [ovs-dev] ovsdb-server.7: Describe message ordering between "update" and "transact". | expand |
On Mon, Apr 22, 2019 at 2:00 PM Ben Pfaff <blp@ovn.org> wrote: > > This comes up sometime and it's best to document it. > > Signed-off-by: Ben Pfaff <blp@ovn.org> > --- > Documentation/ref/ovsdb-server.7.rst | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/Documentation/ref/ovsdb-server.7.rst b/Documentation/ref/ovsdb-server.7.rst > index 4bbe2325ac1f..9be4f2c0cc07 100644 > --- a/Documentation/ref/ovsdb-server.7.rst > +++ b/Documentation/ref/ovsdb-server.7.rst > @@ -1,5 +1,5 @@ > .. > - Copyright (c) 2017 Nicira, Inc. > + Copyright (c) 2017, 2019 Nicira, Inc. > > Licensed under the Apache License, Version 2.0 (the "License"); you may > not use this file except in compliance with the License. You may obtain > @@ -146,6 +146,13 @@ notifications (see below) to the request, it must be unique among all active > monitors. ``ovsdb-server`` rejects attempt to create two monitors with the > same identifier. > > +When a given client sends a ``transact`` request that changes a table that the > +same client is monitoring, ``ovsdb-server`` always sends the ``update`` (or > +``update2`` or ``update3``) for these changes before it sends the reply to the > +``transact`` request. Thus, when a client replies a ``transact`` reply, it can I think you intended to say: when a client s/replies/receives ... > > +know immediately what changes (if any) the transaction made. (If the other > +ordering were used, then the client might have to wait indefinitely.) > + > I am confused. It is better to say: it can *see* immediately the changes it has made? I think there is possibility that there are other changes made by other clients could be notified at the same time, before the reply is received by this client, so it actually cannot tell which changes are made by it. Your description seems to tell the purpose of this is for the client to figure out what has been changed by itself. Or is it really what you wanted to convey and my point is a misunderstanding? And I think I didn't understand why would the client have to *wait indefinitely*. What would it be waiting for? Waiting for its change to get notified? If so, it should not be *indefinitely*, right? I assume it should be: If the other ordering were used, then the client might not see its own change even when the transaction reply is received. Please correct me if I am wrong :)
On Tue, Apr 23, 2019 at 12:32:04PM -0700, Han Zhou wrote: > On Mon, Apr 22, 2019 at 2:00 PM Ben Pfaff <blp@ovn.org> wrote: > > > > This comes up sometime and it's best to document it. > > > > Signed-off-by: Ben Pfaff <blp@ovn.org> > > --- > > Documentation/ref/ovsdb-server.7.rst | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/ref/ovsdb-server.7.rst > b/Documentation/ref/ovsdb-server.7.rst > > index 4bbe2325ac1f..9be4f2c0cc07 100644 > > --- a/Documentation/ref/ovsdb-server.7.rst > > +++ b/Documentation/ref/ovsdb-server.7.rst > > @@ -1,5 +1,5 @@ > > .. > > - Copyright (c) 2017 Nicira, Inc. > > + Copyright (c) 2017, 2019 Nicira, Inc. > > > > Licensed under the Apache License, Version 2.0 (the "License"); > you may > > not use this file except in compliance with the License. You may > obtain > > @@ -146,6 +146,13 @@ notifications (see below) to the request, it must be > unique among all active > > monitors. ``ovsdb-server`` rejects attempt to create two monitors with > the > > same identifier. > > > > +When a given client sends a ``transact`` request that changes a table > that the > > +same client is monitoring, ``ovsdb-server`` always sends the ``update`` > (or > > +``update2`` or ``update3``) for these changes before it sends the reply > to the > > +``transact`` request. Thus, when a client replies a ``transact`` reply, > it can > > I think you intended to say: when a client s/replies/receives ... Yes, thanks. > > +know immediately what changes (if any) the transaction made. (If the > other > > +ordering were used, then the client might have to wait indefinitely.) > > + > > > > I am confused. It is better to say: it can *see* immediately the changes it > has made? I think there is possibility that there are other changes made by > other clients could be notified at the same time, before the reply is > received by this client, so it actually cannot tell which changes are made > by it. Your description seems to tell the purpose of this is for the client > to figure out what has been changed by itself. Or is it really what you > wanted to convey and my point is a misunderstanding? And I think I didn't > understand why would the client have to *wait indefinitely*. What would it > be waiting for? Waiting for its change to get notified? If so, it should > not be *indefinitely*, right? I assume it should be: If the other ordering > were used, then the client might not see its own change even when the > transaction reply is received. Please correct me if I am wrong :) Let me try again. How about this? When a given client sends a ``transact`` request that changes a table that the same client is monitoring, ``ovsdb-server`` always sends the ``update`` (or ``update2`` or ``update3``) for these changes before it sends the reply to the ``transact`` request. Thus, when a client receives a ``transact`` reply, it can know immediately what changes (if any) the transaction made. (If ovsdb-server might use the other order, then a client that wishes to act on based on the results of its own transactions would not know when this was guaranteed to have taken place.) It is not that the client can tell exactly what changes its transaction made; that is not guaranteed. But the client knows that, if its transaction did make any changes, then those changes have already been reported to it by the time it receives the transaction reply. This is especially important if the transaction actually didn't change anything, since otherwise the client would not have any way to know how long to wait for an "update" before concluding that no changes occurred.
On Tue, Apr 23, 2019 at 5:27 PM Ben Pfaff <blp@ovn.org> wrote: > > On Tue, Apr 23, 2019 at 12:32:04PM -0700, Han Zhou wrote: > > On Mon, Apr 22, 2019 at 2:00 PM Ben Pfaff <blp@ovn.org> wrote: > > > > > > This comes up sometime and it's best to document it. > > > > > > Signed-off-by: Ben Pfaff <blp@ovn.org> > > > --- > > > Documentation/ref/ovsdb-server.7.rst | 9 ++++++++- > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/ref/ovsdb-server.7.rst > > b/Documentation/ref/ovsdb-server.7.rst > > > index 4bbe2325ac1f..9be4f2c0cc07 100644 > > > --- a/Documentation/ref/ovsdb-server.7.rst > > > +++ b/Documentation/ref/ovsdb-server.7.rst > > > @@ -1,5 +1,5 @@ > > > .. > > > - Copyright (c) 2017 Nicira, Inc. > > > + Copyright (c) 2017, 2019 Nicira, Inc. > > > > > > Licensed under the Apache License, Version 2.0 (the "License"); > > you may > > > not use this file except in compliance with the License. You may > > obtain > > > @@ -146,6 +146,13 @@ notifications (see below) to the request, it must be > > unique among all active > > > monitors. ``ovsdb-server`` rejects attempt to create two monitors with > > the > > > same identifier. > > > > > > +When a given client sends a ``transact`` request that changes a table > > that the > > > +same client is monitoring, ``ovsdb-server`` always sends the ``update`` > > (or > > > +``update2`` or ``update3``) for these changes before it sends the reply > > to the > > > +``transact`` request. Thus, when a client replies a ``transact`` reply, > > it can > > > > I think you intended to say: when a client s/replies/receives ... > > Yes, thanks. > > > > +know immediately what changes (if any) the transaction made. (If the > > other > > > +ordering were used, then the client might have to wait indefinitely.) > > > + > > > > > > > I am confused. It is better to say: it can *see* immediately the changes it > > has made? I think there is possibility that there are other changes made by > > other clients could be notified at the same time, before the reply is > > received by this client, so it actually cannot tell which changes are made > > by it. Your description seems to tell the purpose of this is for the client > > to figure out what has been changed by itself. Or is it really what you > > wanted to convey and my point is a misunderstanding? And I think I didn't > > understand why would the client have to *wait indefinitely*. What would it > > be waiting for? Waiting for its change to get notified? If so, it should > > not be *indefinitely*, right? I assume it should be: If the other ordering > > were used, then the client might not see its own change even when the > > transaction reply is received. Please correct me if I am wrong :) > > Let me try again. How about this? > > When a given client sends a ``transact`` request that changes a > table that the same client is monitoring, ``ovsdb-server`` always > sends the ``update`` (or ``update2`` or ``update3``) for these > changes before it sends the reply to the ``transact`` request. > Thus, when a client receives a ``transact`` reply, it can know > immediately what changes (if any) the transaction made. (If > ovsdb-server might use the other order, then a client that wishes to > act on based on the results of its own transactions would not know > when this was guaranteed to have taken place.) > > It is not that the client can tell exactly what changes its transaction > made; that is not guaranteed. But the client knows that, if its > transaction did make any changes, then those changes have already been > reported to it by the time it receives the transaction reply. This is > especially important if the transaction actually didn't change anything, > since otherwise the client would not have any way to know how long to > wait for an "update" before concluding that no changes occurred. I think the new version is clear. The use case that a client wants to know if *no* change has occurred is something new to me. Thanks for explain! (I think the order is important even without this use case. In general, a DB client should see its changes as soon as the transaction commit is confirmed (reply). Even a simple test case that verifies if a update to DB is successful would fail.) Acked-by: Han Zhou <hzhou8@ebay.com>
On Wed, Apr 24, 2019 at 10:51:09AM -0700, Han Zhou wrote: > On Tue, Apr 23, 2019 at 5:27 PM Ben Pfaff <blp@ovn.org> wrote: > > > > On Tue, Apr 23, 2019 at 12:32:04PM -0700, Han Zhou wrote: > > > On Mon, Apr 22, 2019 at 2:00 PM Ben Pfaff <blp@ovn.org> wrote: > > > > > > > > This comes up sometime and it's best to document it. > > > > > > > > Signed-off-by: Ben Pfaff <blp@ovn.org> > > > > --- > > > > Documentation/ref/ovsdb-server.7.rst | 9 ++++++++- > > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/ref/ovsdb-server.7.rst > > > b/Documentation/ref/ovsdb-server.7.rst > > > > index 4bbe2325ac1f..9be4f2c0cc07 100644 > > > > --- a/Documentation/ref/ovsdb-server.7.rst > > > > +++ b/Documentation/ref/ovsdb-server.7.rst > > > > @@ -1,5 +1,5 @@ > > > > .. > > > > - Copyright (c) 2017 Nicira, Inc. > > > > + Copyright (c) 2017, 2019 Nicira, Inc. > > > > > > > > Licensed under the Apache License, Version 2.0 (the "License"); > > > you may > > > > not use this file except in compliance with the License. You > may > > > obtain > > > > @@ -146,6 +146,13 @@ notifications (see below) to the request, it > must be > > > unique among all active > > > > monitors. ``ovsdb-server`` rejects attempt to create two monitors > with > > > the > > > > same identifier. > > > > > > > > +When a given client sends a ``transact`` request that changes a table > > > that the > > > > +same client is monitoring, ``ovsdb-server`` always sends the > ``update`` > > > (or > > > > +``update2`` or ``update3``) for these changes before it sends the > reply > > > to the > > > > +``transact`` request. Thus, when a client replies a ``transact`` > reply, > > > it can > > > > > > I think you intended to say: when a client s/replies/receives ... > > > > Yes, thanks. > > > > > > +know immediately what changes (if any) the transaction made. (If the > > > other > > > > +ordering were used, then the client might have to wait indefinitely.) > > > > + > > > > > > > > > > I am confused. It is better to say: it can *see* immediately the > changes it > > > has made? I think there is possibility that there are other changes > made by > > > other clients could be notified at the same time, before the reply is > > > received by this client, so it actually cannot tell which changes are > made > > > by it. Your description seems to tell the purpose of this is for the > client > > > to figure out what has been changed by itself. Or is it really what you > > > wanted to convey and my point is a misunderstanding? And I think I > didn't > > > understand why would the client have to *wait indefinitely*. What would > it > > > be waiting for? Waiting for its change to get notified? If so, it should > > > not be *indefinitely*, right? I assume it should be: If the other > ordering > > > were used, then the client might not see its own change even when the > > > transaction reply is received. Please correct me if I am wrong :) > > > > Let me try again. How about this? > > > > When a given client sends a ``transact`` request that changes a > > table that the same client is monitoring, ``ovsdb-server`` always > > sends the ``update`` (or ``update2`` or ``update3``) for these > > changes before it sends the reply to the ``transact`` request. > > Thus, when a client receives a ``transact`` reply, it can know > > immediately what changes (if any) the transaction made. (If > > ovsdb-server might use the other order, then a client that wishes to > > act on based on the results of its own transactions would not know > > when this was guaranteed to have taken place.) > > > > It is not that the client can tell exactly what changes its transaction > > made; that is not guaranteed. But the client knows that, if its > > transaction did make any changes, then those changes have already been > > reported to it by the time it receives the transaction reply. This is > > especially important if the transaction actually didn't change anything, > > since otherwise the client would not have any way to know how long to > > wait for an "update" before concluding that no changes occurred. > > I think the new version is clear. > The use case that a client wants to know if *no* change has occurred is > something new to me. Thanks for explain! > (I think the order is important even without this use case. In general, a > DB client should see its changes as soon as the transaction commit is > confirmed (reply). Even a simple test case that verifies if a update to DB > is successful would fail.) > > Acked-by: Han Zhou <hzhou8@ebay.com> Thanks! I applied this to master.
diff --git a/Documentation/ref/ovsdb-server.7.rst b/Documentation/ref/ovsdb-server.7.rst index 4bbe2325ac1f..9be4f2c0cc07 100644 --- a/Documentation/ref/ovsdb-server.7.rst +++ b/Documentation/ref/ovsdb-server.7.rst @@ -1,5 +1,5 @@ .. - Copyright (c) 2017 Nicira, Inc. + Copyright (c) 2017, 2019 Nicira, Inc. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain @@ -146,6 +146,13 @@ notifications (see below) to the request, it must be unique among all active monitors. ``ovsdb-server`` rejects attempt to create two monitors with the same identifier. +When a given client sends a ``transact`` request that changes a table that the +same client is monitoring, ``ovsdb-server`` always sends the ``update`` (or +``update2`` or ``update3``) for these changes before it sends the reply to the +``transact`` request. Thus, when a client replies a ``transact`` reply, it can +know immediately what changes (if any) the transaction made. (If the other +ordering were used, then the client might have to wait indefinitely.) + 4.1.7 Monitor Cancellation --------------------------
This comes up sometime and it's best to document it. Signed-off-by: Ben Pfaff <blp@ovn.org> --- Documentation/ref/ovsdb-server.7.rst | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)