Datasheet

their usual account details, and this login is then forwarded on to the database by any applications that
are used. An advantage here is that at no point does the application need to be aware of the security
details entered by the user — it simply forwards them on from its context.
Alternatively, you can use DBMS-specific forms of authentication, which typically involve passing a
username and password combination to the DBMS over a secure connection.
Concurrency Control
With multiple users accessing the same database at the same time, situations can arrive where the data
being used by one user is out of date, or where two users attempt to edit data simultaneously. Many
DBMSes include methods to deal with these circumstances, although they can be somewhat tricky to
implement.
In general, there are three approaches to concurrency control that you can use, which you’ll look at
shortly. To understand them, you must consider an update to be an operation that involves three steps:
1. User reads the data from a row.
2. User decides what changes to make to the row data.
3. User makes changes to the row.
In all cases sequential edits are fine: that is, where one user performs steps 1–3, then another user per-
forms steps 1–3, and so on. Problems arise when more that one user performs steps 1 and 2 based on the
original state of the row, and then one user performs step 3.
The three approaches to concurrency control are as follows:
❑ “Last in wins”: Rows (records) are unavailable only while changes are actually being made to
them (during step 3). Attempts to read row data during that time (which is very short) are
delayed until the row data is written. If two users make changes to a row, the last edit made
applies, and earlier changes are overwritten. The important thing here is that both users might
have read the data for the row (steps 1 and 2) before either of them makes a change, so the user
making the second change is not aware that the row data has already been altered before mak-
ing his change.
❑ Optimistic concurrency control: As with “last in wins,” rows are unavailable only while they
are being updated. However, with optimistic concurrency control, changes to row data that
occur after a user reads the row (step 1) are detected. If a user attempts to update a row that has
been updated since he read its data, his update will fail, and an error may occur, depending on
the implementation of this scheme. If that happens, you can either discard your changes or read
the new value of the row and make changes to that before committing the second change.
Effectively, this could be called “first in wins.”
❑ Pessimistic concurrency control: Rows are locked from the moment they are retrieved until the
moment they are updated, that is, through steps 1–3. This may adversely affect performance,
because while one user is editing a row, no other users can read data from it, but the protection
of data is guaranteed. This scheme enforces sequential data access.
Most of the time, concurrency control is jointly handled by the DBMS and the client application. In this
book, you will be using C# and ADO.NET, and data is handled in a disconnected way. This means that
12
Chapter 1
44063c01.qxd:WroxBeg 9/12/06 10:31 PM Page 12