On Thu, 25 Mar 2004, David Nicol wrote:
> Sounds like locking discipline is not being followed consistently.
>
> lock (or die, or wait and retry -- a blocking lock will do this for you)
> open db file (or wait and retry)
> manipulate db file (or gracefully handle out-of-space)
> close db file (or die - very odd. You opened it didn't you?)
> release lock (or die - again very odd. You got the lock didn't you?)
>
> all the time.
Note also this warning from sleepycat documentation (ISTR that that is the
db used):
...if any thread of control exits for any reason while holding Berkeley
DB resources, recovery must be performed to do the following:
* Recover the Berkeley DB resources.
* Release any locks or mutexes that may have been held to avoid
starvation as the remaining threads of control convoy behind the failed
thread's locks.
* Clean up any partially completed operations that may have left a
database in an inconsistent or corrupted state.
Complicating this problem is the fact that the Berkeley DB library itself
cannot determine whether recovery is required; the application itself must
make that decision. A further complication is that recovery must be
single-threaded; that is, one thread of control or process must perform
recovery before any other thread of control or processes attempts to
create or join the Berkeley DB environment.
---
Charlie
