Thank you both for your replies. I had actually tried passing back a reference first, but I run into a very odd problem. So I changed my hash_init function to something like this:

sub hash_init2  {

    #### DBM Configuration #######################
    my $dbm_file = "file.db";
    my %hash;
    local *DBM;

    my $db = tie %hash, 'MLDBM', $dbm_file, O_CREAT | O_RDWR, 0644 or 
+die "Couldn't not tie to $dbm_file: $!";
    my $fd = $db->fd;
    open DBM, "+<&=$fd" or die "Could not dup DBM for lock : $!";
    flock DBM, "LOCK_EX";
    undef $db;

    #Dumper(%hash);

    return \%hash;
}
[download]

And then I call it from deleteItem as follows:

sub deleteItem {
    my ($self, $del_id) = @_;

    my $hash = hash_init2();
    print Dumper($hash);

    # check if the item actually exists in the database
    if ( exists($hash->{$del_id}) ) {
        delete( $hash->{$del_id} );
    }
    untie($hash);
}
[download]

The odd thing is, the print Dumper call in deleteItem normally doesn't print anything (so the reference points to a null hash, and the delete fails). However, when I uncomment the line Dumper(%hash) in hash_init2, then everything works. As you see, I am not even printing anything, but just reading the values.

Any ideas why this might be happening? Does one need to read from the tied hash in the same scope or something?

I'm guessing that the code you posted isn't the code you're using. To get it to run, I had to make some changes. Here's what I have:

use Data::Dumper;
use MLDBM qw( DB_File );
use Fcntl qw( :DEFAULT :flock );

sub hash_init2  {
    #### DBM Configuration #######################
    my $dbm_file = "file.db";
    my %hash;
    local *DBM;

    my $db = tie %hash, 'MLDBM', $dbm_file, O_CREAT | O_RDWR, 0644
        or die "Couldn't not tie to $dbm_file: $!";
    my $fd = $db->fd;
    open DBM, "+<&=$fd" or die "Could not dup DBM for lock : $!";
    flock DBM, LOCK_EX;
    undef $db;

    return \%hash;
}

my $h = hash_init2();
print Dumper $h;
[download]

I notice that things work as I expect if I throw out all the stuff to do with file locking (everything between the tie line and the return line). My advice is to pick another file to lock (say, "file.db.lock"), and do not much with your "file.db" directly at all. Let MLDBM own that. There's then no reason to catch the value, $db, and no reason to undef it (which might be another problem).

I see what you mean. All that code that I am using came directly from the book CGI Programming with Perl , Chapter 10, Section 2 ("DBM Files"). I am not very experienced with file locking, and I wasn't really interested in the syncronization stuff when we covered it in my OS class (semaphores still send shivers up my spine). I figured I could just copy and paste the code from the book to get it to work, but I guess I was wrong.

So how do you suggest I deal with file locking? As explained in the book, the point of the $db variable is to get the file descriptor. Once that is done, we 'undef' it to decrement the reference count. That way, when hash is untie'd, the changes made to hash are committed to the file. But I guess instead of doing all that, I can use a different file as a lock?

I still find it peculiar that things work when there is a Dumper call in hash_init that reads the values. Can anybody explain why that happens?

Also, can you tell me what you had to change in the code that I posted? Because that really is what I am using..