Ideas wanted for TXN and Concurrent store recovery handling

[Matthias Andree]

"Tom Anderson" <tanderso at oac-design.com> writes:

> a better way to use Berkeley DB?  You could record the process id in a
> seperate lockfile.  Use a generic timeout period, and then check if that
> process is still running after that time.

This is, unfortunately, unreliable because some unrelated process may
have been assigned the process ID and if that happens to be a
long-running process, we've gained nothing.

> If so, continue to wait.  If not,
> change the process id to the current process (retaining the lock) and start
> your recovery process.  Don't know if that can be done atomically.  Try
> sys/sem.h.

Ah, a new idea. Will have to check.

> What if it's hung, but still running?

Well, that is the important issue. It'll just loop, delaying with
select(2), until the cows come home.

> Perhaps you can ping the
> running process by raising a signal.  Don't know if any of that helps
> or if its just a mental fart.

I'd wondered how I can do that without adding such a timeout for each
and every Berkeley DB call and with restarting the time for any progress
the process makes. Hm.

Thanks.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)