QDBM and transactions

[Stefan Bellon]

Matthias Andree wrote:
> Stefan Bellon <sbellon at sbellon.de> writes:

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

I'll have to take a look whether our POSIX layer provides those. But I
fear not.

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

Sorry, my error, of course link() creates hard links. Anyway, my
statement is true. You cannot have hard links under RISC OS either but
have to rewrite the logic using e.g. rename().

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

You may be quite right here.

I just replaced Depot API with Villa API in datastore_qdbm.c but not
including transactions. I noticed that Villa API is _a lot_ faster than
Depot API (that's because it uses B+ trees in order to store the data
rather than a hash table). So even if a complete transactional layer
for QDBM is not worthwile, _if_ we keep QDBM as database backend at
all, it might be still nice switching from Depot to Villa because of
the speedup.

-- 
Stefan Bellon