> From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
>
>>>>Here's the pseudo-code to acquire a DB_ENV handle:
>>>>
>>>> Open/create the DB_REGISTER file
>>>> If the DB_REGISTER file is 0-length
>>>> Write identifying string in the first line
>>>>
>>>>
>>>>
>>>>
>>>There's a race here. It would be better to acquire the exclusive lock
>>>first, then check and/or write the identifying string.
>>>
>>>Yes, fcntl can lock byte ranges beyond EOF, in every implementation I've
>>>heard of.
>>
>> I don't think there's a race here -- all threads of control are
>> writing the same byte strings, I don't think we care which one
>> wins.
>
> That's assuming that writing the identification string is atomic. While
> that will mostly be true, I'd rather not rely on that. I don't think
> lokcing the file first would cause any problems, and it would make the
> code slightly safer (and more portable). Safety is good. :-)
Writing a string under 512 bytes better be atomic. :-)
The trade-off is requiring the ability to lock bytes in a file
that don't yet exist.
>>>Instead of marking all the slots empty, wouldn't it be better to mark
>>>only those that are marked used but aren't locked? This means that you
>>>always have to walk the whole list in the first loop, but that's the
>>>expected case anyway and it doesn't make sense to short-circuit the
>>>error case, and you can merge the second loop into the first. Live
>>>processes will release their slots anyway when they panic out of the
>>>environment.
>>
>> No, that might cause more recovery runs than are necessary.
>>
>> Let's say we find an allocated slot w/o a lock. Call that
>> generation #1, and we then run recovery, starting generation #2.
>> Then, while in generation #2, a still running process from
>> generation #1 drops core, dropping its lock.
>>
>> The next time we review the registry file we will find an
>> allocated slot w/o a lock and will run recovery. That's not
>> going to cause a problem, but it's not necessary, we've already
>> dealt with any failures from generation #1 processes failing.
>
> You're optimising the error case here, which I thnk is a bad idea. In
> general I'd expect gen#1 processes to be aware of this automatic
> recovery scheme and to exit gracefully.
I don't expect them to exit gracefully.
Running processes are likely to get a DB_RUN_RECOVERY return
from a Berkeley DB API call as a result of recovery being run
on their database environment. It's expected applications will
simply exit on DB_RUN_RECOVERY returns, there's no reason for
the application to try and unwind its stack and exit gracefully.
That's why recovery exists, to clean up that kind of problem.
Imagine an application suite with 100 processes. One fails,
and 99 simply exit after receiving DB_RUN_RECOVERY. We're
going to recover the database environment 99 extra times...
and then 99 extra times for the processes caught in the second
recovery run... and so on and so forth.
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 Thu Dec 23 19:22:51 2004