[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_fs/svn_repo repository lock API

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 10 Aug 2012 08:45:23 +0100

Branko Čibej <brane_at_wandisco.com> writes:

> On 10.08.2012 01:15, Philip Martin wrote:
>> Philip Martin <philip.martin_at_wandisco.com> writes:
>>> Yes, I think so. The process executes something like
>>> pragma locking_mode = exclusive;
>>> begin exclusive transaction;
>>> commit transaction;
>>> and then the lock persists until the database connection is closed or
>>> the process exits.
>> I think it might also work with a rollback instead of a commit since
>> exlusive locking mode doesn't release write locks until the database is
>> closed.
> You're aware that your recipe will lock out readers of the database,
> too? I thought the idea was to make the repository read-only, not
> inaccessible.

The rep-cache is only read while building up the commit transaction.
What I think will happen is that commits that are in progress while the
repository is frozen will block for the SQLite timeout and then get some
"could not get write lock" error. I think this error is treated as
non-fatal and the building of the commit transaction will proceed with
the only change being that representations added to the transaction will
not be replaced by ones identified by the rep-cache. The step that
converts the transaction into a revision will be blocked until the
repository is unfrozen.

The rep-cache is only written durint the server-side post-commit
processing, i.e. after the commit and before the post-commit hook.
Once again the write will block for the SQLite and then fail and be
treated as non-fatal. The only change is that representations added in
the commit will not be recorded in the rep-cache.

Since we are taking two locks we need to consider deadlock. The main
write-lock is only held for short periods of time but the rep-cache is
opened with a read-lock for longer. I believe that when a commit holds
both locks it will have taken the rep-cache lock first so freeze needs
to do the same. This means that a big/long commit that has taken the
rep-cache lock (sent the first text delta) will block the freeze until
that commit completes/aborts.

Certified & Supported Apache Subversion Downloads:
Received on 2012-08-10 09:46:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.