On Wed, Aug 27, 2014 at 2:30 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:
> Stefan Fuhrmann wrote on Tue, Aug 26, 2014 at 17:04:27 +0200:
> > Here the guarantees and limitations of the new implementation:
> >
>
> I haven't had a chance to look at the code (sorry), but two quick
> questions based on this summary:
>
> > * No lost updates in revprop file contents even if the
> > SVN caches should be stale.
> > * A connection (svn_fs_t) will always see at least all
> > changes up to and including its own last revprop change.
> > * A new connection will always see all changes made
> > up to the point the connection got created.
> >
> > * On Windows and Unixoids, readers will always see
> > the latest data if they are on the same machine as the
> > writing process.
> > * Depending on OS read cache configuration and if the
> > repository is shared between machines, open connections
> > *might* no see revprop updates or might see them delayed
> > (the open revprop generation file handle may see a stale
> > OS file buffer).
>
> Is starvation possible? i.e., is it possible for the delay to be
> indefinite (assume the reader fs_t does no write operations)? I assume
> the delay would be finite and bounded by a constant if the shared disk's
> local file handles have this property.?
>
This entirely depends on if and when your cluster file system
configuration makes remote changes visible to already open
file handles. Worst case: an existing open connection never
sees the revprop generation bump and will read new data only
if there is no (old) data in cache for the respective revision.
> Is linearizability guaranteed? i.e., if the repository is load-balanced
> across four servers, and I do 'svn ps alpha 1; svn ps beta 2; svn ps
> gamma 3; svn pl', is it possible for the last process to see beta
> without seeing alpha? (e.g., if each svn process gets load balanced to
> a different server.)
>
Writes are handled as they are today, i.e. the cache get bypassed
even for the read step (get all revprops) in a ps operation.
Because the last command, svn pl, opens a new connection,
it will see up-to-date data.
> Would the last scenario work correctly if the second command had been
> an atomic revprop change of property "alpha" with original_value="1"?
> (See ORIGINAL_VALUE parameter of svn_client_revprop_set2().)
>
Yes, the atomicy guarantees are maintained by explicitly bypassing
the cache in this scenario.
> > * Revprop caching may be inefficient if the repository is
> > shared between machines; again depending on OS config.
>
-- Stefan^2.
Received on 2014-08-27 14:49:50 CEST