Daniel Shahaf wrote:
> Julian Foad wrote on Tue, 13 Oct 2009 at 18:06 +0100:
> > You raise the issue of deleting stale references from the cache, and
> > ensuring stale entries do not end up being used in new committed revs.
> > We can invalidate such entries in the cache synchronously with
> > obliteration, but you point out that the reference may have already been
> > read from the cache and stored in a pending transaction before we
> > invalidate it.
>
> Good point, this is possible, but it isn't what I said. The scenario I
> described below (search for 'rBO') is a race condition around the sqlite
> write lock that (theoretically) may cause cache entries for a given
> revision to be first inserted into the DB only after the obliterate of
> that revision has finished.
>
> (I'm thinking of the case where the 'obliterate' gets the sqlite write
> lock before the commit-it-obliterates gets the sqlite write lock.)
OK, I see.
> > Therefore it seems we will need to validate all such
> > references in a new revision txn at commit finalization time. It might
> > be acceptable to abort a commit if it contains any stale reference, and
> > the user could re-try. The more correct action would be to ensure we
> > have a full copy of the rep available until we convert it into a
> > reference at finalization time.
>
> IOW, when we take the write lock to finalize a commit, at that point we
> should make sure that all the reps we refer to are still alive and well.
Yes.
> Unrelated question: Do we keep a history of obliterations? (I see it
> may be undesired for users, but it might make the implementation
> easier...)
Not sure yet. We will not keep a "full" history, because that would
effectively mean meta-versioning the repository, and that is not what
this feature is about. We might want to keep a trace of metadata about
what was obliterated, but my intuition says we should not strictly need
any such info for functional correctness. We will want to record such a
trace as a server log file for external consumption.
For performance, we will need at least a sequence number that enables us
to detect whether an obliteration has occurred since we recorded some
previous sequence number.
> > A way to describe this is that the conceptual "reference count" of a rep
> > needs to include references in pending transactions: if any pending
> > transaction refers to a given rep, then we can't (yet) delete that rep.
> > When we abort a transaction, then we can look through its references and
> > delete any reps for which it was the only reference. That sounds like it
> > would be inefficient to implement in the obvious way but I'm sure we can
> > find a good equivalent.
> >
>
> IOW: if we have other references for the rep, we should obliterate the
> file without physically deleting the rep?
Yes.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407352
Received on 2009-10-14 00:54:27 CEST