QDBM and transactions

[Matthias Andree]

Stefan Bellon <sbellon at sbellon.de> writes:

>> 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.
>
> s/RiscOS/RISC OS/
>
> RiscOS is another operating system which is _not_ related to RISC OS.

Talk about confusion and name law...

> Ok, I had a look at db_lock.c and found how that it's totally
> incompatible with RISC OS. The RISC OS fcntl() supports neither F_SETLK
> nor F_GETLK.

The outer lock layer may substitute flock, the inner layer may
substitute lockf if that helps.

> And as we don't have symlinks under RISC OS, link()
> doesn't work either.

link() creates hard links. All these link()/rename() tricks are
effectively making sure that updates are atomic and/or a certain file
always exists.

> I have however implemented proper file locking in
> the port of GnuPG I did. I need an atomar file operation, and the
> rename is such one under RISC OS. Instead of link() I use the RISC OS
> rename in order to ensure atomar operation. I haven't had a look at how
> fcntl's F_SETLK and F_GETLK are used, but I guess they are more
> difficult to emulate.

QDBM appears to require the user to take care about proper locking; but
AFAICT from the documentation of the FreeBSD QDBM port, the Villa API
doesn't isolate the data base from system crashes, only from application
crashes. I wonder if it's worthwhile.

-- 
Matthias Andree