Stas,
Sounds like you agree with me that downgrading locks from exclusive to
shared is not a problem with the method I described in the last e-mail.
Now you have a concern with upgrading locks from shared to exclusive:
> David, please consider this scenario:
>
> ... At some point in time, processes A and B both read from the dbm via SH
> lock.
>
> 1. A completes its reading and unlocks the DBM, while still having the
> first 4k cached. (A still has the dbm tie()'d.
>
> 2. B wants to write, so it requests an EX lock and gets it granted.
This will not happen. When B requests the EX lock it will block until all of
the other shared locks have been released. Process A has to release the SH
lock somehow for B to get the EX lock. Either A simply finishes and releases
the lock, or A requests an upgrade, is denied, and handles this by releasing
the lock.
When the EX lock is granted (whether from an upgrade or not), by definition
no other processes can have a SH lock and be reading the database. No other
processes can have a first 4k cached because no other processes can have the
file open.
>From the flock manpage: "A single file may not simultaneously have both
shared and exclusive locks."
> 3. B modifies the data in the first 4k, syncs it and releases the lock.
>
> 4. A asks for SH or EX lock, gets it, but its cache is invalid.
>
> => we have a data corruption (especially in the case A does writing into
> the first 4k)
David Harris
President, DRH Internet Inc.
[EMAIL PROTECTED]
http://www.drh.net/
-----Original Message-----
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 10:22 PM
To: David Harris
Cc: mod_perl list
Subject: RE: dbm locking info in the guide
On Thu, 22 Mar 2001, David Harris wrote:
> Two points about switching from exclusive mode to shared mode:
>
> (1) When downgrading from EX to SH, no other processes need to have cached
> data invalidated because no one else can have the database open. There is
no
> cache in other processes, therefore none to be invalidated.
>
> Explanation: Lets say the method for downgrading a lock from EX to SH is
> like this: write data, sync(), flock(FLOCK_SH), read data. Until the
> flock(FLOCK_SH) nobody else can have the database open because of the
> exclusive lock. Therefore, there will not be any other processes with the
> database open and the first 4k cached in memory when the sync() happens.
David, please consider this scenario:
... At some point in time, processes A and B both read from the dbm via SH
lock.
1. A completes its reading and unlocks the DBM, while still having the
first 4k cached. (A still has the dbm tie()'d.
2. B wants to write, so it requests an EX lock and gets it granted.
3. B modifies the data in the first 4k, syncs it and releases the lock.
4. A asks for SH or EX lock, gets it, but its cache is invalid.
=> we have a data corruption (especially in the case A does writing into
the first 4k)
> (2) When downgrading from EX to SH, our processes does not need to
> invalidate cached data because its cached data is correct at the sync()
and
> the data on disk will not be changed until the database is closed.
>
> Explanation: Again we downgrade form EX to SH by doing this: write data,
> sync(), flock(FLOCK_SH), read data. Our cache remains valid the entire
time
> here. With the sync(), data in our cache is written to disk, so at that
> point we are good. Then after the flock(FLOCK_SH) we are still good
because
> the shared lock prevents anyone else from writing to the database and
> changing the data on disk. There is no need to do a re-tie().
That's correct.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
