Philip Martin wrote on Mon, Mar 05, 2012 at 10:50:29 +0000: > Hyrum K Wright <hyrum.wri...@wandisco.com> writes: > > > On Sat, Mar 3, 2012 at 5:31 AM, <stef...@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
