Daniel Shahaf <danielsh_at_elego.de> writes:
> Philip Martin wrote on Mon, Mar 05, 2012 at 11:21:21 +0000:
>> Daniel Shahaf <danielsh_at_elego.de> writes:
>>
>> >> 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?
>>
>> I'm worried about the case where the FS passed to
>> svn_fs_fs__change_rev_prop has a cache that is already populated. The
>> values in the cache might be out-of-date because some other thread with
>> another FS has written newer values. It looks like change_rev_prop_body
>> will examine the out-of-date cached value when doing the "atomic"
>> update.
>
> The values will be in a cache under a key of the form (N,g), but the
> cache lookup will use a key (N,g'), where $g' > g$, and will therefore
> fail. Here, $N$ is a revnum and $g$ is a revprop generation.
Suppose the cache gets populated in the atomic change process with
revprop generation g. Some other process writes to the repository
creating revprop generation g' making the cache in the atomic process
out-of-date. Now the atomic process takes the write lock and does the
"atomic" revprop change using the out-of-date cache.
Without the cache change_rev_prop_body would return
SVN_ERR_FS_PROP_BASEVALUE_MISMATCH if the current value doesn't match
the supplied value. The cache means the current value might be
out-of-date.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-03-05 12:51:41 CET