On Wed, Aug 27, 2014 at 2:30 PM, Daniel Shahaf <d...@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.
