Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday November 20, 2002
10:28 PM

The Ugliest Hack

[ #9049 ]

I was lazy. Bad lazy. On one system that I put together, I had Security object inherit from my Database object that instantiates a DBI object. Just in case I missed a commit or rollback, I had a fallback in a DESTROY method that would do the commit or rollback for me, depending upon whether or not there was an error. Stupid, stupid, stupid. I was bit by this bug before and now I've been bit again.

When the Security object goes out of scope, the reference count to the Database object and the DBI object also drops to zero. Because Perl does not guarantee the order in which things are garbage collected, I periodically had my DBI object go out of scope before the DESTROY method is called, leaving me with a potential automatic rollback on data that should be commited. The solution?

  my $sec = Security->new( $cgi );
  my $dbh = $sec->{_dbh}; # bump up the reference count

  # lots of code

  undef $sec

$dbh is never used in the program, but by bumping up the reference count to the DBI object and explicitly undefing the Security object, I forced it to fall out of scope before the DBI object, thus ensuring that I could commit or rollback my data. The next iteration of my code will remove the DESTROY method.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.