Relational Theory for Computer Professionals

Chapter 8. Transactions

For tyme ylost may nought recovered be

—Geoffrey Chaucer: Troilus and Criseyde (c. 1385)

The transaction concept is only tangentially relevant to most users. Well, this isn’t quite true—if you’re a programmer writing database applications, then you certainly need to know what the implications of transactions are for the way you write your code. But you don’t need to know much more than that. And if you’re an interactive user, you probably don’t even need to know that much. On the other hand (as I’ve said several times previously, more or less), if you want to be able to lay honest claim to having at least a broad understanding of what database technology is all about, then you do need to have, among other things, a basic appreciation of what transaction management entails.

As I’ve also said previously, transaction management isn’t really a relational topic as such. However, it’s interesting to note that the original research—the research, that is, that put the concept on a sound scientific footing—was all done in a specifically relational context.^[60]

What’s a transaction?

A transaction is a program execution, or part of a program execution, that constitutes a logical unit of work. It begins when a BEGIN TRANSACTION statement is executed and ends when either a COMMIT statement or a ROLLBACK statement is executed, where:

• BEGIN TRANSACTION is normally (and desirably) explicit.

• COMMIT signifies successful termination, and is also normally explicit.

• ROLLBACK signifies ...