On Mon, 2004-01-05 at 07:03, Martyn J. Pearce wrote:
> On Mon, Dec 22, 2003 at 05:41:27PM -0600, david nicol wrote:
> >
> > open advisory file
> > lock advisory file (shared for reading, exclusive for writing)
> > tie data file
> > access data file
> > untie data file
> > unlock advisory file
> > close advisory file
> Why the advisory file? I mean, why not lock the data file directly?
>
> Mx.
that works too. The first time I worked with dbm files, it was
with an implementation that produced both a .pag and a .dir file
for a database, so there was no one data file to lock. If I just use
C<opendbm> and let Perl select an implementation, I don't know what
the file name is going to be. It could be foo, it could be foo.db, it
could be both foo.dir and foo.pag. So if I use foo.advisory_lock for
the advisotyr lock, I'm safe regardless of implementation. I'm also
safe from the implementation needing the flock bits if it uses them.
I don't know that they do, but I also don't know that they don't.
Also what would happen if you got your lockfile open syntax wrong
and accidentally clobbered your data?
So I consider using a separate advisory file a best practice. I
have never done a performance comparison, but owuld be curious to see
one.
--
david nicol
"Take your time." -- Allan Quaterman
