Guaranteeing Data Integrity

191Chapter 12 Guaranteeing Data Integrity After completing this chapter, you will be able to: ■ ■ Understand ADO.NET’s use of optimistic concurrency ■ ■ Perform transactions that include

191

Chapter 12

Guaranteeing Data Integrity

After completing this chapter, you will be able to:

■

■ Understand ADO.NET’s use of optimistic concurrency

■

■ Perform transactions that include multiple record updates

■

■ Spread transactions across multiple databases

Database programming would be a meaningless task if there were no way to guarantee the integrity of the data Having a single user update a single record with no one else to interrupt the process is one thing But what happens when you have dozens—or hundreds—of users all trying to update records in the same tables, or even the same records, at the same time?

Welcome to the world of transactions—database operations that enable multiple record

updates to be treated as a single unit This chapter introduces ADO.NET’s take on the trans-action and how your code can work with the database to ensure safe and sound data

Note The exercises in this chapter all use the same sample project: a program that simulates the transfer of funds between bank accounts Although you will be able to run the application after each exercise, the expected results for the full application might not appear until you complete all exercises in the chapter.

Transactions and Concurrency

In today’s Web-based, highly-scalable 24/7/365 world, it’s a given that multiple users will attempt to simultaneously modify the content in your database As long as each user is up-dating different records, concerns about data conflicts occurring between those users are minimal But when two users start competing for the same records, the safety of the data itself becomes a serious issue

Consider two users, Alice and Bob, who are using the same event reservations system to pur-chase tickets for an upcoming concert Because the seats for the concert are numbered, only

a single user can purchase a numbered ticket for a specific seat The sales system sells tickets

in two steps: (1) it reads the reservations table to locate the next empty seat, and (2) it up-dates the record to assign a user to the previously looked-up seat

Figure 12-1 shows three possible scenarios when Alice and Bob use the system at approxi-mately the same time

Alice: Read

Scenario #1

Alice: Read

Scenario #2

Alice: Read

Bob: Read Alice: Write Bob: Write Bob: Write Bob: Write Alice: Write

Scenario #3

FIGURE 12-1 The risks of multiuser access to data.

Assume that seats 100 and 101 are available and will be reserved in that order In Scenario

#1, Alice completes her transaction for seat 100 before Bob even begins requesting an open seat, so there aren’t any data conflicts But Scenarios #2 and #3 show potential problems Depending on how the system is designed, it’s possible that either Bob or Alice will be with-out a reservation In Scenario #3, if the system tells both Alice and Bob that 100 is the next seat available, Alice will get the reservation even through Bob updated the system first This

“last one wins” situation is a common difficulty to be overcome in database development Another potential problem occurs when a database update takes place in multiple parts When you transfer money from your savings account to your checking account, the database records (at least) two distinct updates: (1) the debit of funds from the savings account, and (2) the credit of those same funds into the checking account As long as both operations oc-cur, the record of the transfer is sound But what happens if the database crashes after the withdrawal of funds from the savings account, but before those funds make it into the check-ing account?

Databases attempt to resolve all these conflicts and more by employing transactions A

transaction is a single unit of database work that is guaranteed to maintain the integrity and

reliability of the data It does this by adhering to ACID, the four rules that define the

transac-tion, which are as follows:

■

■ Atomicity The transaction is all or nothing If any part of the transaction cannot

com-plete, whether due to invalid data, constraint limitations, or even a hardware failure, the entire transaction is cancelled and undone After this reversal completes, the state of the involved records is the same as if the transaction never occurred

■ Consistency The transaction, when complete, will leave the database in a valid state

This aspect of transactions often details with constraints For example, when deleting

a parent record, child records bound by a foreign key constraint must be modified to remove the parent reference, deleted from the database, or if they remain, the transac-tion must be canceled

■

■ Isolation This property has to do with multiuser scenarios When a transaction is

active, other users or processes that attempt to access the involved records are not al-lowed to see those records in a semicomplete state The database must either provide those other processes with the pretransaction content of the records, or force those

processes to block, or wait, until the transaction is complete.

■

■ Durability Durable transactions are robust enough to overcome any type of database

failure, and if they are damaged so that they cannot be recovered, they are ultimately

reversed Modern databases achieve this using transaction logs, a secondary repository

of all database modifications that can be “played back” to recover damaged data if needed

Robust databases such as SQL Server ensure that updates made to individual records meet all these ACID requirements For updates made to multiple records, especially those that involve different tables, ACID applies only if you specifically wrap the updates within the database’s platform-specific implementation of a transaction

A transaction begins when you specifically tell the database that you need one, and it ends

when you either commit the transaction—making all changes that took place within the transaction permanent—or issue a rollback—a cancelling or reversal of the entire transaction Database systems also employ record locking: the temporary protection of records, record

blocks, or entire tables from use by other processes during the lifetime of a transaction or other data operation The isolation property of ACID is a typical record-locking function, al-though there are other manual and automated actions in which a database will lock records Record locking allows programmers to resolve the seat reservation issues previously posed

by Alice and Bob If Alice locks seat 100 pending completion of the reservation process, Bob will not have access to that record Instead, he must either wait until the reservation system makes a seat number available or reserve a seat that is not currently locked

Note Although record locking is a traditional method of protecting records, it is often not ef-ficient, and sometimes not even possible, when dealing with disconnected, highly-scalable sys-tems such as busy web sites Such syssys-tems must use other methods of protecting records that must be restricted to a single user or session Some of these alternatives are described in this chapter, on page 194.

Concurrency is the art of when to apply a record lock There are two main flavors of

concurrency:

■

■ Pessimistic concurrency Records destined to be updated are locked when they are

first accessed and read Only the user holding the lock has full access to the record, including the ability to modify it At some point, the record must be released, either through a formal release of the lock or through an update-and-commit process that completes the update Pessimistic concurrency is useful when allowing two users up-date access to the same record could prove problematic

■

■ Optimistic concurrency Records are left unlocked during the read-write interval and

are locked by the database only at the moment of update This type of record locking

is good for those times when records are rarely or never accessed by two users at once,

or when the risks associated with having two users update those records in parallel are small Limited locks allow for high scalability, although with the increased potential for data conflicts

ADO.NET, with its focus on disconnected data processing, uses optimistic concurrency Unfortunately, this method leaves some applications open to data conflicts of the type expe-rienced by Alice and Bob There are data-specific methods that help avoid, or even eliminate,

these problems, even when pessimistic concurrency is not available The SqlCommandBuilder

class uses one such method when it builds data modification statements for the target data-base table Consider an update statement that modifies several fields in a customer table:

UPDATE Customer SET FullName = @NewName,

Address = @NewAddress, Phone = @NewPhone

WHERE ID = @OriginalID

If User A and User B are both updating the record at the same time, with User A modifying

Address and User B correcting Phone, the “last one wins” rule will apply in the absence of

pessimistic concurrency SqlCommandBuilder attempts to reduce such issues by including all the original data values in the update query’s WHERE clause.

UPDATE Customer SET FullName = @NewName,

Address = @NewAddress, Phone = @NewPhone

WHERE ID = @OriginalID

AND FullName = @OriginalName

AND Address = @OriginalAddress

AND Phone = @OriginalPhone

This changes the update system to “first one wins” because any changes made to the record will fail to match some of the “original” values submitted by the second user—one that still has the original premodified image of the record—and thus prevent the update request from

making additional changes without first obtaining the “new original” version of the record In

SQL Server table updates, a rowversion column can be used in the same way because interim

updates to the record change that column’s value automatically

/* - versiontrack column is of type rowversion */

UPDATE Customer SET FullName = @NewName,

Address = @NewAddress, Phone = @NewPhone

WHERE ID = @OriginalID

AND versiontrack = @OriginalRowVersion

Note Some database platforms support statements that let you sidestep ADO.NET’s preference

for optimistic concurrency The Oracle SELECT statement, for example, includes a FOR UPDATE

clause that applies a persistent lock to the record until it is modified in a subsequent statement

or is otherwise released.

Depending on how you manage your ADO.NET database connections and connection-pooling options, such SQL statements might provide access to true pessimistic concurrency If you choose

to use such features, be sure to fully test your implementation, and be aware of changes to ADO.NET

in future releases that might affect your use of such statements.

Using Local Transactions

ADO.NET includes support for transactions with a single database through the System.

Data.Common.DbTransaction class In the SQL Server provider, this base class is overridden

by the System.Data.SqlClient.SqlTransaction class The OLE DB and ODBC providers imple-ment transactions through the System.Data.OleDb.OleDbTransaction and System.Data.

Odbc.OdbcTransaction classes, respectively.

Note The remaining discussion of transactions focuses on the SQL Server provider’s

imple-mentation The OLE DB and ODBC implementations are identical, although some of the internal aspects vary by target database Some OLE DB or ODBC-accessible databases might not support transactions.

Using a transaction to enclose multiple update statements is simple:

1 Open a connection to the database with a SqlConnection object.

2 Create a SqlTransaction instance on that connection.

3 Issue SQL statements within the context of the transaction.

4 Either commit or roll back the transaction.

5 Close the database connection.

Instead of creating instances of SqlTransaction directly, you generate connection-specific transactions using the SqlConnection object’s BeginTransaction method Transactions work only on open database connections, so you must call the connection object’s Open method

first

C#

using (SqlConnection linkToDB = new SqlConnection(connectionString))

{

linkToDB.Open();

SqlTransaction envelope = linkToDB.BeginTransaction();

Visual Basic

Using linkToDB As SqlConnection = New SqlConnection(connectionString)

linkToDB.Open()

Dim envelope As SqlTransaction = linkToDB.BeginTransaction()

After obtaining a transaction object, add it to any SqlCommand objects that should be part

of the transaction

C#

// - Include the transaction in the SqlCommand constructor.

SqlCommand updateCommand = new SqlCommand(sqlText, linkToDB, envelope);

// - Or add it to an existing SqlCommand object.

SqlCommand updateCommand = new SqlCommand(sqlText, linkToDB);

updateCommand.Transaction = envelope;

Visual Basic

' - Include the transaction in the SqlCommand constructor.

Dim updateCommand As New SqlCommand(sqlText, linkToDB, envelope)

' - Or add it to an existing SqlCommand object.

Dim updateCommand As New SqlCommand(sqlText, linkToDB)

updateCommand.Transaction = envelope

After you’ve issued all the transaction-specific commands, you can commit or roll back the

entire transaction by calling the SqlTransaction object’s Commit or Rollback method.

// - Commit the transaction.

envelope.Commit();

// - Rollback the transaction.

envelope.Rollback();

Visual Basic

' - Commit the transaction.

envelope.Commit()

' - Rollback the transaction.

envelope.Rollback()

You should always call Commit or Rollback explicitly If you dispose of the object or allow it

to go out of scope without calling one of these two methods, the transaction will be rolled back, but at a time determined by the NET garbage collection system

Both Commit and Rollback—and the initial BeginTransaction call as well—generate

excep-tions if there is a database or local failure in the transaction Always surround these calls with exception handling statements

C#

try

{

envelope.Commit();

}

catch (Exception ex)

{

MessageBox.Show("Error saving data: " + ex.Message);

try

{

envelope.Rollback();

}

catch (Exception ex2)

{

// - Although the rollback generated an error, the

// transaction will still be rolled back by the

// database because it did not get a commit order.

MessageBox.Show("Error undoing the changes: " + ex2.Message);

}

}

Visual Basic

Try

envelope.Commit()

Catch ex As Exception

MessageBox.Show("Error saving data: " & ex.Message)

Try

envelope.Rollback()

Catch ex2 As Exception

' - Although the rollback generated an error, the

' transaction will still be rolled back by the

' database because it did not get a commit order.

MessageBox.Show("Error undoing the changes: " & ex2.Message)

End Try

End Try

If you include SELECT statements in your transactions, especially on records that will not be

modified as part of the transaction, there is a chance that these selected records might become locked during the transaction, preventing other users from making modifications to them, or even reading them Depending on the configuration of your SQL Server instance,

SELECT statements might apply “read locks” on the returned records by default To avoid

such locks, exclude SELECT statements from your transactions or use the WITH (NOLOCK) hint in your SQL Server SELECT statements.

SELECT * FROM OrderEntry WITH (NOLOCK)

WHERE OrderDate >= DATEADD(day, -3, GETDATE())

Processing with a Local Transaction: C#

1 Open the “Chapter 12 CSharp” project from the installed samples folder The project

includes a Windows.Forms class named AccountTransfer, which simulates the transfer of

funds between two bank accounts

2 Open the code for the AccountTransfer class Locate the GetConnectionString function,

which is a routine that uses a SqlConnectionStringBuilder to create a valid connection

string to the sample database It currently includes the following statements:

builder.DataSource = @"(local)\SQLExpress";

builder.InitialCatalog = "StepSample";

builder.IntegratedSecurity = true;

Adjust these statements as needed to provide access to your own test database

3 Locate the TransferLocal routine This code performs a transfer between two bank

ac-count records using a local SqlTransaction instance A using block fills most of the procedure’s body Just inside this using statement, immediately after the comment

“The database must be opened to create the transaction,” add the following code: linkToDB.Open();

// - Prepare a transaction to surround the transfer

envelope = linkToDB.BeginTransaction();

These statements open the database connection (a requirement for using transactions) and start the transfer’s transaction

4 Just after the “Prepare and perform the withdrawal” comment, add the following

statements:

sqlText = @"UPDATE BankAccount SET Balance = Balance - @ToTransfer

WHERE AccountNumber = @FromAccount";

withdrawal = new SqlCommand(sqlText, linkToDB, envelope);

withdrawal.Parameters.AddWithValue("@ToTransfer", toTransfer);

if (OptFromChecking.Checked)

withdrawal.Parameters.AddWithValue("@FromAccount", CheckingAccountID);

else

withdrawal.Parameters.AddWithValue("@FromAccount", SavingsAccountID);

These lines create a parameterized UPDATE query within the context of the envelope transaction The presence of envelope as the final argument to the SqlCommand

con-structor provides this context

5 Just after the “Prepare and perform the deposit” comment, add the following lines:

sqlText = @"UPDATE BankAccount SET Balance = Balance + @ToTransfer

WHERE AccountNumber = @ToAccount";

deposit = new SqlCommand(sqlText, linkToDB, envelope);

deposit.Parameters.AddWithValue("@ToTransfer", toTransfer);

if (OptFromChecking.Checked)

deposit.Parameters.AddWithValue("@ToAccount", SavingsAccountID);

else

deposit.Parameters.AddWithValue("@ToAccount", CheckingAccountID);

This block is the same as in the previous step, but it performs the second half of the two-statement transaction

6 Just after the “Perform the transfer” comment within the try block, add these three

statements:

withdrawal.ExecuteNonQuery();

deposit.ExecuteNonQuery();

envelope.Commit();

This set of lines performs the actual transaction, issuing distinct UPDATE queries for

the withdrawal and deposit halves of the atomic transaction The third method call,

Commit, makes the transaction permanent Any failure on any of these three lines raises

an exception in the subsequent catch block.

7 Just after the “Do a rollback instead” comment, within the inner try block, add the

fol-lowing line:

envelope.Rollback();

This line undoes the transaction in case of failure in the previous step

8 Run the program The form that appears lets you transfer funds between a checking

and a savings account If you try to transfer an amount greater than the amount in the source account, the transaction fails due to “check constraints” defined on the SQL Server table that prevent negative values Select From Checking To Savings as the

trans-fer type and enter 1000 in the Transtrans-fer Amount field (or any value that exceeds the

bal-ance in the checking account) Click Transfer The error that occurs triggers a rollback of the transaction In contrast, operations that transfer funds within the limits of the source account’s balance result in a successful, committed transfer

Processing with a Local Transaction: Visual Basic

1 Open the “Chapter 12 VB” project from the installed samples folder The project

in-cludes a Windows.Forms class named AccountTransfer, which simulates the transfer of

funds between two bank accounts

2 Open the code for the AccountTransfer class Locate the GetConnectionString function,

which is a routine that uses a SqlConnectionStringBuilder to create a valid connection

string to the sample database It currently includes the following statements:

builder.DataSource = "(local)\SQLExpress"

builder.InitialCatalog = "StepSample"

builder.IntegratedSecurity = True

Adjust these statements as needed to provide access to your own test database

3 Locate the TransferLocal routine This code performs a transfer between two bank

ac-count records using a local SqlTransaction instance A Using block fills most of the procedure’s body Just inside this Using statement, immediately after the comment

“The database must be opened to create the transaction,” add the following code: