Re: Persisting data across authenticate <-> authorize ?

[prev] [thread] [next] [Date index for 2004/12/13]

On Mon, 13 Dec 2004 01:14:57 -0500, Perrin Harkins <perrin@xxxx.xxx> wrote:
> On Mon, 2004-12-13 at 00:01 -0600, David Nicol wrote:
> > this is essentially exactly the application that DirDB was written for.  Instead
> > of locking and corruption issues with a file based db such as berkeley DB, use
> > the file system's robustness.
> 
> How do you figure?  BerkeleyDB's locking should be at least as good as
> what you can do with flock() and friends from perl.  Have you had
> problems with it?

i may be mistaken, but i have been under the impression that berkeley and
others get corrupted if two processes write to the same open db at the
same time.

DirDB uses directory locking sparingly, usually it just does rename-and-clobber.

 
> > as i am sure that things like Apace::Session are already integrated into the mp
> > framework better than a simple file system based persistence framework that,
> > when i use it, uses a cookie for persistence, that I manage myself,
> > I'm not including
> > the mp list in this response.
> 
> Apache::Session is not integrated with mod_perl in any way, actually.
> The name is misleading.  Your storage module may be of interest to
> others on the list, although you will probably be asked how it compared
> to things like Cache::FastMmap and BerkeleyDB in terms of performance.

i don't have the answers to that.

DirDB maps a tied hash to a directory, with one entry per file. 
Hashrefs turn into
subdirectories.  It is designed to be safe accross NFS, using directory locking
instead of flock() when it has to.  Recent releases handle blessed hashrefs,
restoring them into blessed hashrefs of the same package.

As a persistence framework, the changes are immediate and visible to all other
users of the same DirDB.  When a hashref is assigned into a DirDB structure,
a deep cloning takes place unless the hashref is already tied, which can lead
to unexpected persistence if you aren't designing this behavior into
your system:

my %foo = (one=>1, two=>2);
tie my %persistent, DirDB => '/var/spool/persistentdata';

$persistent{hashref} = \%foo;

now /var/spool/persistentdata/hashref/one and two exist, one byte each

$foo{abc} = 'def''

now /var/spool/persistentdata/hashref/abc is a three-byte file with 'def' in it.

There is a DirDB::FTP package as well, that associates a hash with a remote
directory on an FTP server, which only scales as well as your FTP server -- it
kept killing the one that comes with Debian, for instance.

        -- 
        Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html