On Tue, Apr 23, 2019 at 5:27 PM Ben Pfaff <b...@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 <b...@ovn.org> wrote: > > > > > > This comes up sometime and it's best to document it. > > > > > > Signed-off-by: Ben Pfaff <b...@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 <hzh...@ebay.com> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev