Philip Martin wrote on Mon, Mar 05, 2012 at 10:50:29 +0000:
> Hyrum K Wright <hyrum.wright_at_wandisco.com> writes:
>
> > On Sat, Mar 3, 2012 at 5:31 AM, <stefan2_at_apache.org> wrote:
> >> Author: stefan2
> >> Date: Sat Mar 3 11:31:17 2012
> >> New Revision: 1296604
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1296604&view=rev
> >> Log:
> >> Certain operations, e.g. svn ls, will contain timestamp and author
> >> information from many different revisions. A list of all projects
> >> in the root of the wordpress repository will open, read and close
> >>>75.000 revision property files (3 reads for each list entry)
> >>
> >> This commit implements revprop caching. It will be activated as
> >> part of the full-text caching option.
> >>
> >> Since revprops may be written by other threads or processes, we
> >> need to track the revprop changes. A new special file contains a
> >> counter that will be increased each time revision properties get
> >> rewritten.
> >>
> >> This counter is internally called "revprop generation" and will be
> >> read upon the first revprop access for given fs_t. Later changes
> >> may remain invisible for that fs_t. This behavior is in line with
> >> our revprop handling in other parts of FS_FS. If a revprop gets
> >> rewritten, the fs_t doing the write will use the new generation
> >> from that point on and will thus see all caches up to and including
> >> its own.
> >>
> >> Since the revprop generation becomes part of the cache key, each
> >> fs_t will only see revprops from its generation. It may also
> >> create new cache entries tagged with that generation, i.e. those
> >> would appear to be outdated for newer fs_t. But that will simply
> >> cause a benign false negative upon lookup. No fs_t will see
> >> data that got replaced before that fs_t was created.
> >
> > How does this potentially interact with revprop packing?
>
> What about atomic revprop changes? I don't see what ensures that the
> old value read by change_rev_prop_body is the most up-to-date value.
>
ffd->revprop_generation is used as part of the cache key, the file is
written before the write-lock is released and read again as soon as the
write-lock is taken. Do you see a problem?
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Received on 2012-03-05 12:11:27 CET