my %hash = qw(foo 1  bar 2);
foo(%hash);
bar(\%hash);
[download]

The foo() subroutine gets a list, ('foo', 1, 'bar', 2). It can copy this list into a hash, but changes to that hash have no effect on %hash. bar() gets a reference to the original hash; changes to the reference affect %hash in the outer code.

Similarly, if you want to maintain the tie when you pass your hash out of hash_init(), you need to return a reference. Otherwise you're just copying the contents of your hash into another, non-tied, hash. You could also pass a hash reference for it to tie, i.e. hash_init(\%hash)

See perldoc perlreftut, perldoc perlref, and Beginning Perl's Chapter on References.

Somni is correct about using a reference to pass the tied hash around. In the code you have, you'd return \%hash inside hash_init. Outside, you'd say my $hash_ref = hash_init() and then $hash_ref->{$id} to access some part of it.

That aside, I notice you flock after the hash has been tied. I think it would be better to get a lock on something before the hash is tied. You may want to use a separate lock file for that purpose. I don't know for a fact that what you're doing now leaves room for a problem, but it looks suspicious to me.

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).