> Branko Ă„Ĺ’ibej <brane@xbc.nu> writes:
>
> Probably not; some sort of counter would be nice, with a forced check
> every N times (like forced fscks on some filesystems). Of course, we
> should also force a check any time some process gets a DB_RUN_RECOVERY
> from BDB.
That should never happen in a database environment; of course,
if it does happen, then you should run recovery.
> Keith, in the past I noticed that when a process with that has opened a
> BDB environment crashes, leving love locks behind, other processes that
> are using the same environment may hang indefinitely. This is what
> usually causes SVN repositories to get in a "wedged" state. This leads
> me to believe that relying on BDB to detect this situation and return
> DB_RUN_RECOVERY to the other processes isn't reliable.
Yes, that is correct; if a thread of control dies while holding
a Berkeley DB lock or mutex, then other threads of control are
potentially going to hang, requesting a lock or mutex that can
never be granted.
The next release of Berkeley DB will allow processes to clean
up held locks. (For example, thread A opens a database and
locks page 5, and dies. In our next release, another thread of
control can release that lock and clean up as necessary, which
allows the application to proceed.)
However, there's no way to do a similar clean up for mutexes,
the locks Berkeley DB uses to serialize access to shared data
structures. We could clean up the mutex, but that won't help
as that might allow threads of control to access corrupted data
structures (for example, incorrectly linked lists).
> Am I missing something here, or is using a separate server process with
> exclusive access to the repository truly the only way to completely
> avoid such hangs?
A separate server process doesn't necessarily avoid such hangs,
but you're on the track of the idea.
To rephrase: the "server process running in a different address
space" architecture gives you two things: first, a random
process dying cannot leave a database environment mutex or lock
wedged, because the server is holding the locks/mutexes on
behalf of the other processes. Sure, the server could fail and
leave locks/mutexes held, but the server is probably written a
lot more carefully than a random process talking to the server.
As Mark Twain (or Andrew Carnegie) is reputed to have said, "Put
all your eggs in the one basket and --- WATCH THAT BASKET."
Second, if the server dies, you're immediately notified and you
don't have to somehow detect the failure of a random process.
The downside of this architecture is you're sacrificing a lot
of performance because you're forced to talk some kind of IPC
to the server.
That said... I talked to Michael Pilato about this, and I raised
the idea of Subversion moving to a client/server architecture.
Client/server solutions are fundamentally easier to administrate
than embedded databases. Given the large number of ways that
Subversion can be accessed, ensuring conformance to Berkeley
DB's "rules of recovery" is not trivial, and may itself cost you
significant performance.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic@sleepycat.com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
---------------------------------------------------------------------
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:24:02 2004