From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]> 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
