On Mon, Oct 12, 2015 at 12:10 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> Hi,
>
>
>
> Another reply:
>
>
>
> How does this affect multiple processes accessing the same repository?
>
For FSFS:
The effect is the same as using 2 different svn_fs_t instances
because the cache uses a svn_fs_t-specific prefix (that UUID)
in the key, such that the contents is not visible to any other
svn_fs_t instance. Using the process-global membuffer cache
for storage merely ensures fair memory usage / prioritization.
Within a svn_fs_t, the cache has a "dead man switch". Whenever
you write a revprop or read it with REFRESH set, the cache
gets invalidated by resetting the UUID. That means, only for
as long as e.g. the repos layer explicitly says "use the cache"
for every revprop read, will data be cached at all.
BDB simply ignores the new feature and operates as before.
FSX has a different revprop caching mechanism and will use
the new API to manage that cache more efficiently.
> This caching looks like a nice speedup in some common cases, but I’m
> wondering if we are adding new race conditions on revision property
> updates. We had to add specific atomic revprop change apis to resolve/limit
> some older race conditions and this looks at the surface like it might
> introduce a few new cases.
>
That is a valid concern. However, svn_fs_fs__change_rev_prop
via change_rev_prop_body always reads the current revprop data
from disk and invalidates the cache. So, within FSFS, propset
does not depend on cached data and cache invalidation ensures
that it will "see" its own revprop changes.
Outside the FS backends, only users of svn_fs_revision_prop2
and svn_fs_revision_proplist2 may be affected. Everyone outside
lib_repos calls those with REFRESH set, i.e. there is no risk of
using a stale result to short-circuit a propset. Within lib_repos,
only svn_repos_fs_change_rev_prop4 reads *and* writes revprops.
And this function explicitly requests the latest revprop data.
Therefore, I think the write path is pretty safe. If this patch series
introduced a problem then it is one of the read queries in lib_repos
not returning the latest data when they should. And those invocations
are easy to review.
-- Stefan^2.
> *From:* Stefan Fuhrmann [mailto:stefan.fuhrmann_at_wandisco.com]
> *Sent:* zondag 11 oktober 2015 14:26
> *To:* Subversion Development <dev_at_subversion.apache.org>
> *Subject:* Efficient revprop access in lib_repos
>
>
>
> [This is the rationale and additional documentation to an upcoming
>
> set of commits.]
>
>
> When changing a revprop, we provide the following visibility guarantees:
>
> 1. A request that ends before the set_revprop started, sees the old value
> (duh!).
> 2. A request that starts after the set_revprop completes, sees the new
> value.
> 3. A request that starts before the set_revprop completes, may see the old
> or
> the new value and may not be consistent about it.
>
Received on 2015-10-12 10:04:22 CEST