in reply to Re: DBM::Deep: Cannot allocate transaction ID
in thread DBM::Deep: Cannot allocate transaction ID

G'day Ken,
thanks for your quick help.
I checked the source code of File.pm in DBM/Deep/Engine/.
the error caused by transaction slots full
the question become how to reset transaction slots ? I am keeping to debug.

sub begin_work {
    use Data::Dumper;
    my $self = shift;
    my ($obj) = @_;

    unless ($self->supports('transactions')) {
        DBM::Deep->_throw_error( "Cannot begin_work unless transaction
+s are supported" );
    }

    if ( $self->trans_id ) {
        DBM::Deep->_throw_error( "Cannot begin_work within an active t
+ransaction" );
    }

    my @slots = $self->read_txn_slots;
    print Dumper(@slots);
    my $found;
    for my $i ( 0 .. $self->num_txns-2 ) {
        print  "i,$i\n";
        next if $slots[$i];

        $slots[$i] = 1;
        $self->set_trans_id( $i + 1 );
        $found = 1;
        last;
    }
    unless ( $found ) {
        DBM::Deep->_throw_error( "Cannot allocate transaction ID" );
    }
    $self->write_txn_slots( @slots );

    if ( !$self->trans_id ) {
        DBM::Deep->_throw_error( "Cannot begin_work - no available tra
+nsactions" );
    }

    no Data::Dumper;
    return;
}

[download]

Replies are listed 'Best First'.
Re^3: DBM::Deep: Cannot allocate transaction ID (semi-OT) (updated)
by AnomalousMonk (Archbishop) on Jan 10, 2021 at 16:17 UTC 
    sub begin_work {
    use Data::Dumper;

    ... lotsa code

    no Data::Dumper;
    return;
}

    [download]

    This doesn't address your immediate problem, but application code modules like Data::Dumper do not follow the lexical scoping rules that pragma modules like strict, warnings and integer follow.

    The effects of the use Data::Dumper; statement are seen from the point in the file at which the module is use-ed at compile time and in all code beyond that point. 

    Win8 Strawberry 5.8.9.5 (32)  Sun 01/10/2021 10:52:26
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings
# pm#11126693

foo();  # try disabling this statement

print Dumper [ qw(1 2 3) ];  # print() on unopened filehandle Dumper

# foo();  # try enabling this statement

sub foo {
    use Data::Dumper;
    print Dumper [ qw(a b c) ];

    no Data::Dumper;  # has no effect
    print Dumper [ qw(x y z) ];
    }

print Dumper [ qw(9 8 7) ];  # prints as expected
^Z
$VAR1 = [
          'a',
          'b',
          'c'
        ];
$VAR1 = [
          'x',
          'y',
          'z'
        ];
print() on unopened filehandle Dumper at - line 5.
$VAR1 = [
          '9',
          '8',
          '7'
        ];

    [download]
    Same results running under Perl version 5.30.3.1.

    Update: Another little twist to consider is the effect of adding a declaration of the Dumper subroutine in the main package before the first call to Dumper (and before the use Data::Dumper; statement): 

    sub Dumper;

print Dumper [ qw(1 2 3) ];  # print() on unopened filehandle Dumper

    [download]
    What happens and why? Is there another way to identify Dumper to the compiler as a subroutine? What would happen if one wrote: 
    ### sub Dumper;

print Dumper([ qw(1 2 3) ]);  # print() on unopened filehandle Dumper

    [download]
    (I see the same results under both versions 5.8.9 and 5.30.3.)

    Give a man a fish:  <%-{-{-{-<

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom