Chapter 15: Transactions

Loc Hoang

CS 157B

Definition A transaction is a discrete unit of

work that must be completely processed or not processed at all.

Example: Transferring funds from a checking account to a saving account.

Desirable Properties To ensure data data integrity. The

database system must maintain the ACID properties.

Atomicity Consistency Isolation Durability

ACID continue… Atomicity. Either all operations of the

transaction are reflected properly in the database, or none are.

Consistency. Execution of a transaction in isolation (that is, with no other transaction executing concurrently) preserves the consistency of the database.

ACID continue... Isolation. Even though multiple

transactions may execute concurrently, the system guarantees that, for every pair of transactions Ti, and Tj, it appears to Ti, that either Tj finished execution before Ti started, or that Tj started execution after Ti finished. Thus, each transaction is unaware of the transactions executing concurrently in the system.

ACID continue... Durability. After a transaction

completes successfully, the changes it has made to the database persist, even if there are system failures.

Transaction States

Because failures occurs, transaction are broken up into states to handle various situation.

Transaction States Active, the initial state; the

transaction stays in this state until while it is still executing.

A transition is terminated only if it has either been committed or aborted.

Transaction States

Partially committed, After the final statement has been executed

At this point failure is still possible since changes may have been only done in main memory, a hardware failure could still occur.

Transaction States

The DBMS needs to write out enough information to disk so that, in case of a failure, the system could re-create the updates performed by the transaction once the system is brought back up. After it has written out all the necessary information, it is committed.

Transaction States

Committed- after successful completion.

Once committed, the transaction can no longer be undone by aborting it.

Its effect could be undone only by a compensating transaction.

Transaction States

Failed, after the discovery that normal execution can no longer proceed

Once a transaction can not be completed, any changes that it made must be undone rolling it back.

Transaction States Aborted, after the transaction has been

rolled back the the database has been restored to its state prior to the start of the transaction.

The DBMS could either kill the transaction or restart the transaction.

A transaction may only be restarted as a result of some hardware or software error, and a restarted transaction is considered a new transaction.

Concurrent execution

DBMS usually allow multiple transaction to run at once.

The transaction could by run serially (one after another) or they could be interleaved(switching back and forth between transactions)

Concurrent execution

Pro: Improved throughput and resource

utilization Could take advantage of multi-processsing

Reduce waiting time.Avoid short transaction waiting on long transaction

Improve average response time.

Concurrent execution

Con: Creates many complications in

data consistency, including cascading roll-backs.

Consistency could be compromise even if each individual transaction is correct.

Schedules

DBMS needs to make sure that all transaction schedules preserves the consistency of the database.

A schedule is the chronological order in which instructions are executed in a system.

Schedule

A schedule for a set of transaction must consist of all the instruction of those transaction and must preserve the order in which the instructions appear in each individual transaction.

Schedule exampleT1-----------------read(A)A:=A-50write(A)read(B)B:= B+ 50write(B)

T2-----------------

read(A)temp: A * 0.1A: A-tempwrite (A)read(B)B:=B +tempwrite(B)

Schedule 1.

Serial Schedule

In schedule 1 the all the instructions of T1 are grouped and run together. Then all the instructions of T2 are grouped and run together. This type of schedules are called serial.

Concurrent transactions do not have to run serially as in the next examples.

Interleaved ScheduleT1-----------------read(A)A:=A-50write(A)

read(B)B:= B+ 50write(B)

T2-----------------

read(A)temp: A * 0.1A: A-tempwrite (A)

read(B)B:=B +tempwrite(B)

Schedule 2

Conflict Equivalent

Schedule 1 and 2 produce the same result even though they have different sequence. It could be shown that Schedule 2 could be transform into Schedule 1 with a sequence of swaps, so Schedule 1 and 2 conflict equivalent.

Not all schedules are conflict equivalent. Consider Schedule 3

Inconsistent ScheduleT1-----------------read(A)A:=A-50

write(A)read(B)B:= B+ 50write(B)

T2-----------------

read(A)temp: A * 0.1A: A-tempwrite (A)read(B)

B:=B +tempwrite(B)

Schedule 3.

Serializability

Suppose that A and B were bank accounts with initial amounts of $1,000 and $2,000 respectively. Then after Schedule 1 and Schedule 2 are run. The result is $850 for A and $2,150 for B. And the sum A+B is still $3000.

After Schedule 3 runs, account A is $950 and B $2100. The sum A+B is now $3,050 which is incorrect, since $50 was magically created in the process.

Conflict Serializability

Schedule 2 is consistent because is it conflict equivalent to Schedule 1. Since Schedule 1 is serial, Schedule two is said to be conflict serializable.

Instructions within a schedule could be

swapped if they do not conflict. Instructions do not conflict if they access different data item or if they access the same data item non of the instructions are write instructions.

Conflict Serializability

Schedule 2 could be turn into Schedule 1 with the by the following steps:

Swap write(A) of T2 with read(B) of T1 Swap read(B) of T1 with read(A) of T2 Swap write(B) of T1 with write(A) of T2 Swap write(B) of T1 with read(A) of T2