QDBM and transactions

[Pavel Kankovsky]

On Fri, 29 Oct 2004, Matthias Andree wrote:

> Stefan Bellon <sbellon at sbellon.de> writes:
> 
> > I've just had a look at the QDBM documentation. We currently use the
> > Depot API in QDBM. But there exists another one: the Villa API. And the
> > Villa API has transaction support. Perhaps we can indeed maintain a
> > transactional QDBM together with a BerkeleyDB one?
> 
> Feel free to take a stab and implement a transactional interface for
> QDBM; if you have any questions, this list is the right place to ask.
> 
> If you need a crash detector (because QDBM doesn't by itself figure when
> it needs to recover/rollback, Berkeley DB doesn't), check db_lock.c and
> how it's integrated in datastore_db.c.
> 

> We're effectively using an outer lock layer (traditional fcntl locked
> file) and an inner lock layer (special character cell based locking
> process tracker developped by Pavel and me little) which is currently
> tailored for Berkeley DB's needs but can be used by other data bases,
> too, if needed. The inner layer requires record locks, not sure if OS/2
> or RiscOS can provide these.

Matthias is giving me too much credit, he did all the hard work.

But let's get back to the topic: the locking mechanism depends on

1. one tri-state (unlocked/shared/exclusive) lock
   to guarantee exclusive access to recovery jobs et al (this is
   the "outer layer"),

2. multiple bi-state (unlocked/locked) locks on 0/1 cells & fsync()
   to make the detection of dead processes possible; it must be possible 
   to test whether a given lock is locked in a non-blocking and 
   non-destructive way (this is the "inner layer"),

3. alarm() for periodic checks of dead processes.

One can emulate the locks by whatever means as long as the emulation 
guarantees 1. the desired kind of mutual exclusion, and 2. unexpected 
termination of a process (including the total system crash) unlocks any 
locks. One might even avoid record locks if multiple single-cell files 
were use instead of a single multi-cell file but the overhead might be 
pretty high.

BTW: Matthias, you should avoid stdio calls in a signal handler. Most libc
routines, including stdio, are not reentrant.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."