chapter 15: transactions loc hoang cs 157b. definition n a transaction is a discrete unit of work...
TRANSCRIPT
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