On Wed, Nov 21, 2012 at 10:49:51AM -0800, Gurucharan Shetty wrote: > > > > This is because we cannot be sure that the commit will be effective. > > The database supports many clients all working concurrently, which means > > that any update we ship to the database could be invalidated, wholly or > > partially, by some other client acting before us. > > > > ovsdb_idl_txn_commit() tries to document this: > > > > * Committing a transaction rolls back all of the changes that it made to > > the > > * IDL's copy of the database. If the transaction commits successfully, > > then > > * the database server will send an update and, thus, the IDL will be > > updated > > * with the committed changes. */ > I get it now. Though in my case, the IDL does not seem to get updated > with the DB > value (which I guess is because they are all write_only columns).
That can only happen after the ovsdb-server sends the update back and then ovsdb_idl_run() reads the update. The update should take effect whether the columns are write-only or not. It is possible that this intermediate state doesn't ever become visible in the IDL because a second commit is sent, processed by ovsdb-server, and then sent back as an update before the next ovsdb_idl_run() call, so that only the net effect of both transactions becomes visible. You might be able to get a good view of what's happening on the server end by looking at conf.db with "ovsdb-tool -mm show-log". "-vjsonrpc" also helps, but the JSON is more or less unreadable without patience and some knowledge of the OVSDB protocol. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
