لطفا منتظر باشید ...
Chapter 7: Sessions, Transactions, and Locks
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.
