in reply to Making credit processing atomic

If using a proper transactional DB system (ie I use Mysql with InnoDB tables) you simply turn AutoCommit => 0 during your intitial database connection. Then you wrap your entire transaction in an eval block, begin and end the transaction inside, and check for errors following, like the following:
eval { $dbh->begin_work; $self->insert_file($file); $self->$handler($file); $self->update_package_table($file,$type); $self->update_city_summary($file->{'processed_scans'}{$type}); $dbh->commit; }; if ($@) { warn stamp()."Transaction aborted because $@ Rolling back transact +ion\n"; eval { $dbh->rollback }; if ($@) { warn stamp()."Rollback Unsuccessful because $@"; } else { warn stamp()."Rollback Successful"; } }

This way everything is either commited if all is successful, or if anything dies within your eval block, or the script is aborted during the transaction, all the work done within the eval block is rolled back. Note that the subs that are called within the eval block call many other subs and touch many different tables.

Be aware that if you have a mixture of tables being commited to (InnoDB and MYIsam) and the transaction is rolled back, only the transactional aware tables take the rollback. The Non-transactional tables keep whatever was done to them.

As far as checking for errors and dying when appropriate, well that's up to you in your code.

Replies are listed 'Best First'.
Re^2: Making credit processing atomic
by Anonymous Monk on Apr 12, 2005 at 19:02 UTC
    I should have been clearer in my original post. The problem arises because a credit authorization/capture can execute successfully, but the database can still fail. I suppose I could automatically credit those transactions where the database fails, but what if I do if the credit doesn't execute properly? The issue I'm trying to overcome is making the RDBMS and the credit authorization act atomically. =)