On Wed, Apr 24, 2019 at 10:51:09AM -0700, Han Zhou wrote: > On Tue, Apr 23, 2019 at 5:27 PM Ben Pfaff <[email protected]> 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 <[email protected]> wrote: > > > > > > > > This comes up sometime and it's best to document it. > > > > > > > > Signed-off-by: Ben Pfaff <[email protected]> > > > > --- > > > > 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 <[email protected]>
Thanks! I applied this to master. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
