Re: rollback ineffective with AutoCommit enabled in do_transaction?

[prev] [thread] [next] [Date index for 2005/05/22]

At 1:17 PM -0400 5/22/05, Perrin Harkins wrote:
>It sounds like the best solution is to use a DBI error handler so 
>you can easily tell when you have a DBI error vs. some other kind. 
>For example, David Wheeler's Exception::Class::DBI:
>http://search.cpan.org/~dwheeler/Exception-Class-DBI-0.92/lib/Exception/Class/DBI.pm
>
>Then you only issue an explicit rollback when you get a non-DBI error.

I think there's an easier way to tell whether I should issue a 
rollback: just check whether AutoCommit got reset. It never hurts to 
do the rollback, so the only reason to even check that is to avoid 
the warning.

Is there a reason why using an error handler is better than the code below?


sub do_transaction {
     my $class = shift;
     my ( $code ) = @_;

     # Turn off AutoCommit for this scope.
     # A commit will occur at the exit of this block automatically,
     # when the local AutoCommit goes out of scope.
     local $class->db_Main->{ AutoCommit };
    
     # Execute the required code inside the transaction.
     eval { $code->() };
     if ( $@ ) {
	my $commit_error = $@;

         # For PostgreSQL:
	# It appears that AutoCommit gets reset if a db error causes a
	# rollback. In that case, we don't need to rollback here
	# (Ima::DBI will complain), but if there's a non-db error, we
	# do want to rollback

	if (!$class->db_Main->{ AutoCommit }) {
	    eval { $class->dbi_rollback }; # might also die!
	}
	die $commit_error;
     } else {
	$class->dbi_commit;
     }
}


        -- 
        Aneel Nazareth -- http://eye-of-newt.com/nazareth --