Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.jpl.nasa.gov (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: need advice - writing a database system
Keywords: database, dbm
Message-ID: <1991May3.165954.303@jpl-devvax.jpl.nasa.gov>
Date: 3 May 91 16:59:54 GMT
References: <1991May3.093532.19393@ccu.umanitoba.ca> <1991May03.143716.827@convex.com>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 30

In article <1991May03.143716.827@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
: From the keyboard of rahard@eeserv.ee.umanitoba.ca (Budi Rahardjo):
: :   - When I update a record, I want to save it right away.
: :     Do I have to close the dbm file (dbmclose) and re-open it again ?
: 
: No.
: 
: :     ie. Is there away I can update the dbm file without closing it ?
: 
: You can use the reset operator if you're careful.  It is documented 
: to flush the database cache.  As of 3.018, its primary effect is
: to generate a coredump, but as of 4.003, it appears to work just fine.

It's a write-through cache, so the file is updated when you modify the
variable.  The only purpose of flushing the cache is on the read
side--to resynchronize with changes that someone else might have made
to the file.  It's the moral equivalent of declaring the file
"volatile".

Other than that, I agree with everything Tom said.  I might add that if
you only have a single process modifying the database, you don't have
to worry much about locking or synchronizing, as long as you do things
in an order that won't confuse the readers of the database.

You mentioned that you want to assign new uids--you might take a hint
from kernel pid assignment and only do the dirty work every now and then,
coming up with a batch of free uids to draw from efficiently.  If you
work it right you can even do the work when the machine is otherwise idle.

Larry