No database is an island. It is possible to imagine a scenario where a database is accessed by one and only one user, all changes are made and saved in a proper order, and nobody forgets to floss. Back on Earth, databases are usually created to be shared. Even the desktop databases, Microsoft Access and OpenOffice BASE, can potentially be shared on the network, and RDBMS servers were specifically designed from the ground up to support multiuser environments.
When more than one user accesses the same set of data, a new set of problems arises: What data should be visible to each of the users? Whose modification should take precedence? What is the guarantee that the data changes will not be lost during the execution of a lengthy database procedure? The answer to these (and many other problems) comes with the introduction of sessions, transactions, and locks.
Let's rephrase the preceding questions in the RDBMS vocabulary:
- Transactions offer solutions to potential data consistency problems.
- Locks deal with data concurrency problems.
- Sessions represent the context in which transactions and locks live.