On Wed, Oct 22, 2008 at 9:31 AM, David Glasser <glasser_at_davidglasser.net> wrote:
> - svn_fs_fs__inc_rep_reuse (unlike svn_fs_fs__set_rep_reference) is
> used outside of the control of the FSFS lock. Thus its
> read-modify-write can have race conditions, leading to two different
> rep key with the same reuse number. Now, I'm not 100% sure how much
> of a problem this is; it would be good to document the point of the
> reuse number somewhere (unless I'm missing it). But I think it's to
> enable our dumb
> compare-if-a-node-has-changed-by-if-its-rep-key-has-changed thing to
> work, right? And so there could be a subtle, difficult-to-diagnose
> problem if two reps end up with the same reuse number. I'm not sure
> how to fix that; the obvious thing to try is wrapping the read and
> write inside a transaction (with retry loop), but I don't remember if
> SQLite transactions work that way. Alternatively, maybe SQLite has
> special handling for atomically incrementing counters?
Easier solution. The point of the reuse column, AFAICT, is *not* to
do a reference count. It's just to uniquify references to the rep.
So switch it from a number to a string, and qualify the string by the
name of the transaction that is creating the reference. You can stick
a counter for the current transaction in foo.txn/next-ids or
something. (Then you still might have to worry about concurrent
writes to the same transaction, but of course that situation is full
of problematic race conditions in FSFS anyway; fortunately all you
have to to avoid those is to avoid mod_dav_svn like the plague.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-22 22:32:46 CEST