Branko ÄŒibej <brane@xbc.nu> writes:
> C. Michael Pilato wrote:
>
>>Keith Bostic <bostic@abyssinian.sleepycat.com> writes:
>>
>>> As a springboard for that discussion, I propose we find a
>>> serialization point for all threads of control using a
>>> Subversion repository so we can determine if a thread of
>>> control is the first thread of control entering the database
>>> environment after a possible application or system failure.
>>
>>My suggestion is that libsvn_fs_base grows the same serialization that
>>mod_db4 uses, which is based around the use of a shared memory segment
>>with a reference count in it.
>>
> There is a pretty fundamental problem with using a reference count
> like that. If a process that is accessing BDB crashes after having
> incremented the refcount, the refcount is gets out if sync and is
> useless. Also, other processes that are already running might wedge on
> a lock owned by the crashed process. I see no way to resolve this.
We have the libsvn_repos lock, which is the current mechanism to
ensures that recovery gets exclusive access. Normal read/write
repository access, such as svn_repos_open(), takes a non-exclusive
lock, while "special" access, such as svn_repos_recover(), takes an
exclusive lock.
Suppose svn_repos_open() were first to make a non-blocking attempt to
take an exclusive lock, if that fails it just carries on as at present
and tries to take a non-exclusive lock. If however svn_repos_open()
manages to take an exclusive lock then it can do whatever it wants
(perhaps run recovery?) and then it can drop the exclusive lock, take
a non-exclusive one and continue as at present.
This would mean that recovery would get run whenever anything accessed
a repository that was not otherwise being accessed, is that the
desired behaviour? Should be simple to implement, but I don't know
what sort of performance effect it would have. Do we really want to
run recovery that often?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 03:25:29 2004