[ovs-dev] [PATCH] ovsdb-server.7: Describe message ordering between "update" and "transact".

[Han Zhou]

On Tue, Apr 23, 2019 at 5:27 PM Ben Pfaff <blp at 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 at ovn.org> wrote:
> > >
> > > This comes up sometime and it's best to document it.
> > >
> > > Signed-off-by: Ben Pfaff <blp at 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 at ebay.com>