On Tue, Aug 12, 2014 at 12:59 PM, Philip Martin <philip.martin_at_wandisco.com>
wrote:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > 1. client sends MKCOL
> > 2. apache process MKCOL and populates txn_dir_cache
> > 3. apache sends MKCOL response
> > 4. apache clears MKCOL request pool
> > 5. client sends MERGE
> > 6. apache process MERGE
> >
> > 5 can happen before 4 since two processes are involved but can 6 happen
> > before 4? I've not seen it happen with the worker MPM but I'm not
> > familiar with all the MPMs.
>
> This could happen if 4 and 6 occur in different threads/processes but
> since the txn_dir_cache is per-thread or per-svn_fs_t any cache from a
> MKCOL will not be visible to MERGE. So there is no txn_dir_cache when
> apache/mod_dav_svn runs the pre-commit and so no cache to become
> out-of-date.
>
The solution seems to be to simply destroy the txn_dir_cache
instance at the begin of the commit. That comes at some extra
cost but that is still proportional to the size of the commit.
The only sequence that would get us into real trouble is
thread / process A: modify txn
thread / process B: modify txn
thread / process A: modify txn (via same fs_t as before)
Since A won't re-read the directory contents and may therefore
return "path not found" errors or miss earlier modifications to a
given node / sub-tree and use a new copy for the following mods.
But I guess we don't support that sequence at all.
-- Stefan^2.
Received on 2014-08-12 18:08:42 CEST