> I pointed this out here in Sheffield yesterday when I proposed that we just
> rip out revprop caching from 1.8 and trunk, because there's no way to make
> it work for the kind of configurations that would need it most (i.e., large
> installations with multiple servers and load balancing).
>
> The
On 22.08.2014 01:39, Evgeny Kotkov wrote:
>> We (Sergey Raevskiy and I) had some time to
>> examine the revision property caching feature, and there are some conclusions
>> that we would like to share. In brief, there are certain conditions when
>> this
>> feature can actually *wreak havoc* in t
> We (Sergey Raevskiy and I) had some time to
> examine the revision property caching feature, and there are some conclusions
> that we would like to share. In brief, there are certain conditions when this
> feature can actually *wreak havoc* in terms of the repository consistency and
> possible
> [...]
>
> I haven't looked at the implementation, but if your description is correct,
> then we're definitely in trouble.
>
> I would have expected that the unversioned-metadata (i.e., currently only
> revprop) generation would always be updated regardless of cache settings,
> and never be cached
[Note: I'd like to split this into two threads, one about revprop
caching and another about named atomics]
On 20.08.2014 13:21, Evgeny Kotkov wrote:
> We (Sergey Raevskiy and I) had some time to
> examine the revision property caching feature, and there are some conclusions
> that we would like t
We (Sergey Raevskiy and I) had some time to
examine the revision property caching feature, and there are some conclusions
that we would like to share. In brief, there are certain conditions when this
feature can actually *wreak havoc* in terms of the repository consistency and
possible corruption
6 matches
Mail list logo
