QDBM and transactions

[Stefan Bellon]

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.

Ok. I'm not sure whether I have the time in the near future, but
indeed, I'd like to keep QDBM in the main trunk and therefore do
something about it.

> 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.

s/RiscOS/RISC OS/

RiscOS is another operating system which is _not_ related to RISC OS.

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. And as we don't have symlinks under RISC OS, link()
doesn't work either. 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.

-- 
Stefan Bellon