QDBM and transactions
matthias.andree at gmx.de
Fri Oct 29 10:23:59 EDT 2004
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
> 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.
More information about the Bogofilter-dev