> 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. I
(I apologize in advance for the horrible line wrapping my mailer will do.)
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
> > Now you have a concern with upgrading locks from shared to exclusive:
> >
> > > David, please consider this scenario:
> > >
> > > ... At some point in time, processes A an
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:
>
> > Dav
t; 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, 2
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, there
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 allowe
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-r
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
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
> 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 o
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 pr
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 cac
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
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
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 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 y
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 t
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
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 th
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
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
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 time and therefore ready to be used. This will work
22 matches
Mail list logo
