apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr-util/dbm/sdbm sdbm.c
Date Tue, 08 May 2001 16:49:55 GMT
From: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
Sent: Tuesday, May 08, 2001 11:25 AM


> > The latter is the only option (short of a synchronized / distributed cache
> > thingameebob). The mtime isn't going to be fine-grained enough to give you
> > proper invalidation. Two changes within the same second will cause data
> > corruption.
> 
> ... uh.... have you looked at tdb?  http://sourceforge.net/projects/tdb
> 
> it's a multi-read, multi-write 'trivial' database (1024 lines)
> _with_ locking, with gdb-like API syntax.
> 
> and it _doesn't_ have data corruption problems on multi-write access.
> 
> [oh, and it has a shared-mem - mmap - option, too]


Nice code, limited portability however.  Some network locking schemas will
grab the one-byte lock and lock down the page.  Don't know if that will break
the schema.  The other [obvious] issue is licensing.  But if you cared to add
the appropriate connector within apr_dbm, I don't see anyone objecting.  The
whole idea behind apr_dbm is to extend to such 3rd party databases such as
the 'biggies' (ndbm, gdbm etc), or our own lightweight solution (sdbm).

We aren't trying to make sdbm 'the answer' to a shared database across 1,000
servers in a cluster :-)  Just a simple dropin where no other (efficient)
alternative exists.

Bill





Mime
View raw message