apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/dbm/sdbm sdbm.c
Date Tue, 01 May 2001 01:49:55 GMT
-1. Please back out.

You cannot lock the file only during write operations. See sdbm_private.h --
copies of the file's data sits in memory. If User B goes and works with the
file, then the cached block for User A becomes invalid. Now, if User A goes
and does some work against the invalid block and writes that back out, then
you've got corruption.

I am mildly against the concept, in general, for SDBM (since people can turn
to other DBM implementations), but if you come up with a patch that solves
the issues, then we could certainly discuss it.

The previous changes have looked good since there was no real functional or
semantic change. This one isn't going to work, unfortunately.

A client app could open/close the SDBM to keep the contention duration
shorter. Another alternative (ugly) would be to flush the cache after all
write operations (thus losing its entire benefit).

There are some other issues with this patch, but it's kind of moot...

Cheers,
-g

On Mon, Apr 30, 2001 at 07:03:50PM -0000, wrowe@apache.org wrote:
> wrowe       01/04/30 12:03:49
> 
>   Modified:    include  apr_file_io.h
>                .        CHANGES
>                dbm/sdbm sdbm.c
>   Log:
>     shared sdbm file locking patch, writes/deletes require an excl lock,
>     read/getkeys require a shared lock

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message