In this scenario, we want to issue a financial transfer from one account to another. We may consider the transfer itself as one data task, even though in reality that task involves multiple database operations. At a minimum, we have two UPDATE statements: one to reduce the first account by the transfer amount, and another to increase the second account by the transfer amount.
In reality we may also involve other database operations for that transfer task, such as one or more INSERT statements to track or log the transfer activ- ity, but we will keep this first scenario simple and just consider just the two UPDATE statements.
we want the end result to be as if the transfer was never started in the first place, and both accounts have the same original amounts. This means that we may have to undo, or rollback, the database access statements that were successful in that transfer task. We can undo those changes by issuing an SQL ROLLBACK statement.
When we consider a set of database accesses, each as part of a larger task such as the financial transfer, we formally refer to that task as a database transaction. Let’s also consider that we want the transaction to either com- plete in full or appear to not have occurred at all, that is, in the event that one of the database accesses resulted in an error or condition that prevents us from wanting to make the transaction results permanent and visible to others. As such, we want the resulting effect that either all of the transac- tion’s individual data accesses to appear to have completed or appear to not have occurred at all. This all-or-nothing concept, where all data accesses appear to have completed if the transaction is successful, or none of the data accesses appear to have completed if the transaction fails, means that the transaction is considered atomic. Such a transaction is known as an atomic transaction.
Before we demonstrate the use of commits and rollbacks with database transactions, let’s first discuss the concept of when changes to data are made permanent to the database and are visible to other users or applications that operate on that database. When we issue a database operation that changes data (such with an INSERT, UPDATE, or DELETE statement), that change is generally considered not visible to other database users or applications until the change is committed to the database. Such a commit can either be specified explicitly as an SQL statement, or be implicit or automatic where, immediately after such a change occurs, the DBMS automatically issues a commit. MySQL, MariaDB, and Oracle have autocommit enabled by default, so when we issue an operation that changes the data in a database, the DBMS automatically commits that change to the database, whether or not that operation is part of a larger task that still has other data operations to issue.
Because we may need to assess the outcome of a set of database oper- ations involved in a task before we can decide whether or not to commit or rollback the data changes issued with that task, we may need to first turn off, or disable, autocommit mode. This allows us to later issue a commit or roll- back to data changes once we can make that decision. We can disable—as well as enable—autocommit mode explicitly in MySQL, MariaDB, and Oracle by
changing the value of the autocommit variable. To explicitly disable automatic commitments in this manner, we simply set the value of autocommit to 0, as shown in Figure 8.2.
FIGURE 8.2 Disabling automatic database commitments.
Now operations that change data in a database are in general not immedi- ately visible to other users or applications that interact with that data.1
With automatic commits disabled, the effects of certain database oper- ations may not be immediately made permanent or visible in the database.
To make the effects of those operations permanent and visible, we can issue a COMMIT statement. On the other hand, we may decide that we do not want to keep those changes, say if the changes result with an invalid data value or some other error. In that case, we may wish to undo or reverse those data changes in order to return the database back to a state or set of values that are valid and not in error. To carry out that undoing or reversal of operations, we can issue a ROLLBACK statement. The resulting effect of a ROLLBACK is that those data changes are not permanent nor visible, as if those operations never occurred. It is important to keep in mind that, with automatic commits disabled, a COMMIT or ROLLBACK statement can affect only the database operations issued since the last COMMIT or ROLLBACK statement.
Should we later need to reenable automatic commitments (or wish to enable them if initially disabled), we can do so by changing the autocommit variable value to 1, as shown in Figure 8.3.
Note that when automatic commits are enabled, a ROLLBACK has no effect. More specifically, if we issue a ROLLBACK in that case, there are not any data changes to undo because the changes have already been
1There may be certain rules or data access methods in effect that can affect when changes to data are seen by a given user or application. In general, consider that a user or application can usually see data changes that it issues, but other users or applications cannot until the changes are committed.
automatically committed. Once a database operation has been committed, it cannot be undone with a ROLLBACK. The same goes for a database opera- tion that has been undone with a ROLLBACK—we cannot reapply it with a COMMIT statement alone.
FIGURE 8.3 Enabling automatic database commitments.