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.
