Overview

In an ideal world, a database is accessed by one and only one user, changes are made and saved in a proper order, and malicious intrusion is an unheard of concept. Unfortunately, it doesn't happen like that in the real world. Frequently data must be shared; it might come from different sources, sometimes at unusual times; and rarely, if ever, would a database server be accessed by one user at a time.

Relational databases were designed to work in a multiuser environment. When more than one user accesses the same set of data, a completely different set of problems appears: What data should be visible for the users? Which modification should take the precedence? What is the guarantee that the data changes will not be lost during execution of a lengthy database procedure? The answer to these and many other problems comes in terms of sessions, transactions, and locks.

The transaction is a solution to potential data consistency problems (discussed in detail later in the chapter), while locks deal with data concurrency problems. The session represents the context in which — along with some other things — transactions and locks take place.