Re: Checkpoint less frequently

On Fri, 2003-02-21 at 13:03, Branko Èibej wrote:
[When the monitor fails to keep a process from hitting a stale lock:]
> So we wait for a bit, then kill it.

If the monitor process is started automatically, then it may have been
started by a different user than the one whose process hung. So we
can't kill it.

The following discipline would seem to work, without the need for a
monitor process:

  * Wrap a guard file around the database, per my earlier idea.
    (fcntl-locked, read-locked for normal access, write-locked for
    recovery.)

  * Set the lock timeout (at db creation time).

  * If we time out on a lock, fail the transaction, grab a write lock on
    the guard file, run recovery, and retry.

But it may be inefficient in some cases:

  * If we erroneously time out on a lock, we will still succeed
    eventually, but it may take much longer than it would if we had
    waited. But that problem should be rare.

  * If multiple processes hit the stale lock, they will all run
    recovery. We could avoid that by putting a timestamp in the guard
    file saying when recovery was last run, or we could hypothesize that
    N recoveries doesn't take much longer than one recovery.

I also wonder how many of these problems go away if you instruct
Berkeley DB to use fcntl locks. (That's possible, right?) And what the
cost is in everyday performance, of course.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 19:21:44 2003