Chapter 3. Transaction Management

Substances owe their special importance in the enterprise of identification to the fact that they survive through time. But the idea of survival is inseparable from the idea of surviving certain sorts of change—of position, size, shape, colour, and so forth. As we might expect, events often play an essential role in identifying a substance... Neither the category of substance nor the category of change is conceivable apart from the other.

—Donald Davidson The Individuation of Events

This quote from Donald Davidson comes from a paper he wrote in the field of event theory. Event theory is an entire subdiscipline of philosophy focused on the question of what it means to be an event. As a software architect for a database application, your job is to be an event theorist. Specifically, you identify what changes will occur in your database and how they combine into indivisible sequences that will not leave the database in an inconsistent state.

This is the practice of event management. You then package those indivisible events into a database operation called a transaction. A transaction is a group of database events that must execute without interference from other transactions; and they must execute together or not at all. The transaction helps you guarantee the integrity of the data in your database.

The classic example of a database transaction is the transfer of money from one bank account to another. When executing a transfer, a banking application needs to make sure that both the debit from the source account and the credit to the target account execute. If one should fail, the system should return to the state it was in before the debit. Without the ability to abort the transaction, a successful debit followed by a failed credit (perhaps the server crashed between the two operations) will result in missing money.