Automatic Transaction Handling
The ISO
standard for
SQL defines a particular model for
transactions. It says that a database connection is always
in a transaction. Each and every transaction
will end with either a commit or a rollback, and every new
transaction will begin with the next statement executed. Most systems
also define an
auto-commit
mechanism that acts as if
commit()
is automatically called after each statement.
The DBI standard tries to find a way to let all drivers for all databases appear to offer the same facilities, as much as possible. It does this by relying on the fact that there’s little practical difference between a database that supports transactions but has auto-commit enabled, versus a database that doesn’t support transactions at all.
The DBI standard also tries to ensure that an application written to require transactions can’t accidentally be run against a database that doesn’t support them. It does this by treating an attempt to disable auto-commit as a fatal error for such a database.
Given that the ability to enable and disable auto-commit is
important, the DBI defines a database handle attribute
called AutoCommit that regulates whether or not
DBI should appear to automatically force a data
commit after every statement.
For example, if you issue a statement like
$dbh->do() that deletes some
data within your database, and AutoCommit is set
to a true value, you cannot roll back your change even if the
database supports transactions.
The DBI defaults ...