shemp has asked for the wisdom of the Perl Monks concerning the following question:

Update:Within the code block

Hi all. Simple question.

Is it advisable to use local to temporarily modify parts of a DBD::MySQL db handle for the 1 place in a big program where i want to use a transaction, or is this not going to work like i think?

my $dbh = ...; ... { # enclosing block for transaction # local $dbh->{'AutoCommit'} = 1; # UPDATE - thanks Corion local $dbh->{'AutoCommit'} = 0; local $dbh->{'PrintError'} = 0; # do the transaction queries ... $dbh->commit(); }
What im trying to accomplish is the localized change of the $dbh attributes to do the transaction, then commit it. So as i see it, when i exit the enclosing block, the localized values will go out of scope and the originals will be restored. In reality, the enclosing block will be a function, but i wanted as simple an example as possible.

I already wrote a little test script that seems to work properly, but i am new to transactions, and dont use local that much, and am looking for any possible problems that this may cause.

I am mostly using whats in the MySQL cookbook section 15.4 Using Transactions in Perl Programs, but they dont use local, and using local seems cleaner to me.

Replies are listed 'Best First'.
Re: local & DBD::mysql
by Corion (Patriarch) on Jun 14, 2005 at 21:22 UTC

    One caveat, as gleaned from the Class::DBI source code - this approach seems to leak memory "on older perls", whatever versions that might be. Other than that, I think your approach is fine, as it does automagic cleanup/restoration of the previous state.

    I think that you got the AutoCommit thing wrong though - AutoCommit should be a false value if you want to issue your transaction statements (begin transaction/commit transaction) yourself. But DBI will warn you about ineffective commit statements anyway.

      For this particular app, im using perl v5.8.0 for sun4-solaris, so the memory leak probably wont be an issue - i hope.
        There were memory leaks in v5.8.0 as I learnt from this post; BTW this specific problem was solved in v5.8.6 (don't know which release solved it actually). They're probably unrelated memory leak problems, but I wouldn't bet on v5.8.0 not leaking.

        Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')

        Don't fool yourself.