CTED]
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
On Fri, 23 Mar 2001, David Harris wrote:
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.
That's correct.
Now you have a concern with upgrading locks from shared to exclusive:
David,
Perhaps we have a misunderstanding here. I would NEVER flock(UN) without
having just previously untie()d the database. And I would ALWAYS acquire a
lock immediately before tie()ing the database.
That's the point. We have to write down all the assumptions or people will
do the wrong thing.
On Wed, 21 Mar 2001, Perrin Harkins wrote:
Ok, what about calling sync before accesing the database? (read and write)
Will it force the process to sync its data with the disk, or will it cause
the corruption of the file on the disk, as the process might have a stale
data?
Well, that's
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
As the person who has discovered this bad flaw in DB_File docs and made
sure that the right thing will be done, may be David will have a time to
go further and check up on this issue. I would definitely do it myself,
but there so many things I've
On Thu, 22 Mar 2001, David Harris wrote:
Thanks, David!
I have done some investigation of the sync method in DB_File and this is
what I have determined: the sync method only writes cached information out
to disk. Information already cached in the process is not invalidated
causing a re-read
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
On Thu, 22 Mar 2001, David Harris wrote:
If you want to downgrade a lock from exclusive to shared, sync the
database
and change the lock status. This will allow other readers access to a
fully-written database. No one else will be allowed to
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
On Tue, 20 Mar 2001, Perrin Harkins wrote:
Stas Bekman wrote:
So basically what you are saying is that sync() is broken and shouldn't be
used at all. Something fishy is going on. The purpose of sync() is to
flush the modifications to the disk.
Saving changes to disk isn't the problem.
Ok, what about calling sync before accesing the database? (read and write)
Will it force the process to sync its data with the disk, or will it cause
the corruption of the file on the disk, as the process might have a stale
data?
Well, that's what we don't know. As David Harris pointed out,
On Tue, 20 Mar 2001, Stas Bekman wrote:
Is anyone aware of a safe to way to do multi-process read/write access
through a dbm module other than BerkeleyDB.pm without tie-ing and
untie-ing every time? I thought that was the only safe thing to do
because of buffering issues, but this seems
Perrin Harkins wrote:
Is anyone aware of a safe to way to do multi-process read/write access
through a dbm module other than BerkeleyDB.pm without tie-ing and
untie-ing every time? I thought that was the only safe thing to do
because of buffering issues, but this seems to be implying that
On Tue, 20 Mar 2001, Joshua Chamas wrote:
I know the tie/untie MLDBM::Sync strategy with DB_File is
slow, but what size data are you caching?
I'm not. Well, actually I am, but I use BerkeleyDB which handles its
own locking. I just noticed this in the Guide and figured that either it
was out
On Tue, 20 Mar 2001, Perrin Harkins wrote:
On Tue, 20 Mar 2001, Stas Bekman wrote:
Is anyone aware of a safe to way to do multi-process read/write access
through a dbm module other than BerkeleyDB.pm without tie-ing and
untie-ing every time? I thought that was the only safe thing to
On Wed, 21 Mar 2001, Stas Bekman wrote:
You mean with DB_File? There's a big warning in the current version
saying not to do that, because there is some initial buffering that
happens when opening a database.
The warning says not to lock on dbm fd but an external file!
I think you'll
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
I think you'll still have problems with this technique, unless you
tie/untie every time. I'm looking at the perldoc for DB_File version
1.76, at the section titled "Locking: the trouble with fd". At the very
least, you'd have to call sync
On Tue, 20 Mar 2001, Perrin Harkins wrote:
On Wed, 21 Mar 2001, Stas Bekman wrote:
You mean with DB_File? There's a big warning in the current version
saying not to do that, because there is some initial buffering that
happens when opening a database.
The warning says not to lock
On Tue, 20 Mar 2001, David Harris wrote:
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
I think you'll still have problems with this technique, unless you
tie/untie every time. I'm looking at the perldoc for DB_File version
1.76, at the section titled "Locking: the trouble with fd".
Stas Bekman wrote:
So basically what you are saying is that sync() is broken and shouldn't be
used at all. Something fishy is going on. The purpose of sync() is to
flush the modifications to the disk.
Saving changes to disk isn't the problem. The issue is that some of the
database gets
On Mon, 19 Mar 2001, Perrin Harkins wrote:
While working on adding info on Berkeley DB to the Guide, I came across
this statement:
"If you need to access a dbm file in your mod_perl code in the read only
mode the operation would be much faster if you keep the dbm file open
(tied) all the
20 matches
Mail list logo
