Fix consistency problems with DBM store

Destroy the AnyDBM-tied hash after untying

Google's wisdom seems to indicate that leaving the AnyDBM-tied hash around after
untying it was causing data to not flush to the DBM file... or something. At any
rate the regression test added here confirms inconsistency when using multiple
instances which is fixed by destroying the AnyDBM-tied hash after untying.
This commit is contained in:
Jared Johnson 2015-01-21 16:43:23 -06:00
parent e3187ace0d
commit e76b6a9048
2 changed files with 16 additions and 0 deletions

View File

@ -93,6 +93,7 @@ sub unlock {
my ( $self ) = @_;
close $self->{lock};
untie $self->{tied};
delete $self->{tied};
}
sub get {

View File

@ -16,6 +16,7 @@ __delete();
__get_keys();
__size();
__flush();
__untie_gotcha();
done_testing();
@ -78,3 +79,17 @@ sub __flush {
$db->unlock;
}
sub __untie_gotcha {
# Regression test for 'gotcha' with untying hash that never goes away
$db->lock;
$db->flush;
$db->set( cut => 'itout' );
$db->unlock;
my $db2 = Qpsmtpd::DB::File::DBM->new( name => 'testing' );
$db2->lock;
is( $db2->get('cut'), 'itout',
'get() in second db handle reads key set in first handle' );
$db2->unlock;
$db->flush;
$db2->flush;
}