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

fcntl locks (was: Checkpoint less frequently)

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-02-22 05:18:05 CET

On Fri, Feb 21, 2003 at 01:41:36AM -0500, Greg Hudson wrote:
> On Fri, 2003-02-21 at 00:18, Branko Cibej wrote:
> > Justin, we'll need a watcher anyway -- it's the only means we have to
> > automatically unwedge a repository if a client crashes. D'you really
> > thing we can release 1.0 without fixing this totally unacceptable bug?
> ("If a client crashes?" If we're using ra_svn or ra_dav, the server
> should have a chance to clean up. As I understand it, the issue arises
> when a server process terminates uncleanly--such as when you interrupt
> an svn command using ra_local, since in that case the "client" and
> "server" are in the same process.)

Yah, ra_local or the server process. "Client of the FS" maybe :-)

> On Unix, anyway, it seems like a fcntl-locked guard around the database
> would do the trick without a separate process. Get a read lock for
> normal operation, or a write lock to recover. fcntl locks are
> automatically terminated on process exit, so there is no issue of stale
> locks.

Heh. Funny that you should mention that. That is exactly what
REPOS/lock/db.lock is for. Problem is, that we don't seem to be using it

Second, an application gets a read lock, but blocks inside of BDB. Thus, the
recovery process can't get in there to do the recover. The administrator has
to go and kill that blocked client.

Really... it seems that we should solve the fcntl thing, or just rip it out
of the SVN codebase.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 22 05:13:49 2003

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