Lec 1 Transaction Processing Concepts

8/11/2019 Lec 1 Transaction Processing Concepts

1/87

Database Systems

Introduction to TransactionProcessing Concepts and

TheoryDr. Ejaz Ahmed

1

Read comments and additional details

given with some slides


2/87

Outline

Introduction to transaction processing Transaction and system concepts

Desirable properties of transactions

Schedules and recoverability Schedules and Serializability

Transaction support in SQL

Summary

2


3/87

Introduction to Transaction

Processing

Single-user VS multi-user systems A DBMS is single-user if at most one user

can use the system at a time

A DBMS is multi-user if many users can use

the system concurrently

Problem

How to make the simultaneous interactions

of multiple users with the database safe,consistent, correct, and efficient?

3


4/87


Processing Computing systems

Single-processor computer system

Multiprogramming

Inter-leaved Execution

Pseudo-parallel processing

Multi-processor computer system

Parallel processing

4


5/87

Concurrent Transactions

5

Interleaved processing

(Single processor)Parallel processing

(Two or more processors)

t1 t2 t1 t2

time

CPU1

CPU2A

B

A

B

CPU1A

B


6/87

What is a Transaction? A transaction T is a logical unit of database processing

that includes one or more database access operations Embedded within an application program

Specified interactively (e.g., via SQL)

Transaction boundaries:

Begin/end transaction Types of transactions

Read transaction

write transaction

Read-set of T: all data items that transaction T reads

Write-set of T: all data items that transaction T writes

6


7/87

Role of Transactions

7

Transaction processing (TP) systems underlie the online

applications. a transaction rate of 15 simple Debit Credit

transactions per second was common, 50 TPS was a goodsystem, 100 TPS was fast, and a 400 TPS system was

characterized as being a very lean and mean system [24].

Teradata capabilities, usage of parallel databases,configuration and tuning etc.


8/87

A Transaction: An Informal Example

Transfer 400,000 from checking account tosavings account

For a user it is one activity

To database:

Read balance of checking account: read( X)

Read balance of savings account: read (Y)

Subtract 400,000 from X

Add 400,000 to Y Write new value of X back to disk

Write new value of Y back to disk

8


9/87

Transactions Example

Usage of ATM to draw money, to collect bills

with dispenser

9


10/87

Database Read and Write

Operations A database is represented as a collection of named

data items Read-item (X)

1. Find the address of the disk block that contains itemX

2. Copy the disk block into a buffer in main memory

3. Copy the item X from the buffer to the program variable namedX

Write-item (X)1. Find the address of the disk block that contains itemX.

2. Copy that disk block into a buffer in main memory

3. Copy itemX from the program variable namedX into its correctlocation in the buffer.

4. Store the updated block from the buffer back to disk (eitherimmediately or at some later point in time).

10


11/87

A Transaction: A Formal

ExampleT1

read_item(X);

read_item(Y);X:=X - 400000;

Y:=Y + 400000;

write _item(X);

write_item(Y);

11

t0

tk


12/87


Processing(Cont.)

Why concurrency control is needed? Three problems are

1. The lost update problem

2. The temporary update (dirty read) problem3. Incorrect summary problem

12


13/87

Operations & Consistent States

Database Operation (read and write)

Non-database Operation (calculations/

formula)

Database Consistent State

Database Inconsistent State

Chapter 17-13


14/87

9-14

Concurrent Transaction

Concurrent transactionsrefer to two or more

transactions that appear to users as they are being

processed against a database at the same time

In reality, CPU can execute only one instruction at a time

Transactions are interleavedmeaning that the operating

system quickly switches CPU services among tasks so that

some portion of each of them is carried out in a given interval

Concurrency problems: lost update and inconsistent

reads


15/87

9-15

Concurrent Transaction Processing


16/87

9-16

Lost-Update Problem


17/87

Transaction Examples

Chapter 17-17

$10 could be lost: inconsistent state

Transaction is committed or is aborted, DB is rollback or undo


18/87

PL/SQL Transaction Example

18


19/87

9-19


20/87

ExampleThe Lost Update

Problem

Chapter 17-20


21/87

Chapter 17-21

FIGURE 17.2

Two sample transactions. (a) Transaction T1.

(b) Transaction T2.


22/87

Chapter 17-22

Some problems that occur when concurrent

execution is uncontrolled. (b) The temporary updateproblem (Dirty Read).


23/87

Lost Update Problem

T1read_item(X);

X:=X - N;

write_item(X);

read_item(Y);

Y:=Y + N;

write_item(Y);

23

T2

read_item(X);

X:=X+M;

write_item(X);

time


24/87

Temporary Update (Dirty Read)

T1read_item(X);

X:=X - N;

write_item(X);

read_item(Y);

T1 fai ls and aborts24

T2

read_item(X);

X:=X+M;

write_item(X);

time


25/87

25

FIGURE 17.3 (continued)

Some problems that occur when concurrent execution is

uncontrolled. (c) The incorrect summary problem

(inconsistent).


26/87

Incorrect Summary ProblemT1

read_item(X);

X:=X-N;

write_item(X);

read_item(Y);

Y=Y+N

Write_item(Y)

26

T2

sum:=0;

read_item(A);

sum:=sum+A;

read_item(X);

sum:=sum+X;

read_item(Y);

sum:=sum+Y

time

Wh t C G W ?


27/87

What Can Go Wrong? System may crash before data is written back to

disk

= Problem of atomicity

Some transaction is modifying shared data whileanother transaction is ongoing (or vice versa)= Problem of serialization and isolation

System may not be able to obtain one or more ofthe data items

System may not be able to write one or more ofthe data items= Problems of atomicity

DBMS has a Concurrency Controlsubsytem toassure database remains in consistent state

despite concurrent execution of transactions 27


28/87

Other Problems System failures may occur

Types of failures:

System crash

Transaction or system error

Local errors Concurrency control enforcement

Disk failure

Physical failures

DBMS has a RecoverySubsystem to

protect database against system

failures

28


29/87


Processing(Cont.) Why recovery is needed?

1. A computer failure (system crash)

2. A transaction or system error

3. Local errors or exception conditions detected

by the transaction

4. Concurrency control enforcement

5. Disk failure

6. Physical problems and catastrophes

29


30/87

Chapter 17-30

Why recovery is needed:(What causes a Transaction to fail)

1. A computer failure (system crash):A hardware orsoftware error occurs in the computer system duringtransaction execution. If the hardware crashes, thecontents of the computers internal memory may belost.

2. A transaction or system error :Some operation in thetransaction may cause it to fail, such as integer overflow

or division by zero. Transaction failure may also occurbecause of erroneous parameter values or because ofa logical programming error. In addition, the user mayinterrupt the transaction during its execution.

Introduction to Transaction Processing (11)


31/87

Chapter 17-31

Why recovery is needed (cont.):3.Local errors or exception conditionsdetected by the

transaction:

- certain conditions necessitate cancellation of the transaction.For example, data for the transaction may not be found. Acondition, such as insufficient account balance in a banking

database, may cause a transaction, such as a fund withdrawalfrom that account, to be canceled.

- a programmed abort in the transaction causes it to fail.

4. Concurrency control enforcement:The concurrency controlmethod may decide to abort the transaction, to be restarted later,

because it violates serializability or because several transactionsare in a state of deadlock (see Chapter 18).



32/87

Chapter 17-32

Why recovery is needed (cont.):5. Disk failure:Some disk blocks may lose their data

because of a read or write malfunction or because of

a disk read/write head crash. This may happen during

a read or a write operation of the transaction.6. Physical problems and catastrophes:This refers

to an endless list of problems that includes power or

air-conditioning failure, fire, theft, sabotage,

overwriting disks or tapes by mistake, and mountingof a wrong tape by the operator.


T ti d S t


33/87

Transaction and System

Concepts Transaction states

BEGIN_TRANSACTION: marks start of transaction

READor WRITE: two possible operations on the

data

END_TRANSACTION: marks the end of the read orwrite operations; start checking whether

everything went according to plan

COMIT_TRANSACTION: signals successful end of

transaction; changes can be committed to DB Partially committed

ROLLBACK(or ABORT): signals unsuccessful end of

transaction, changes applied to DB must be

undone

33


34/87

Transaction States: A state transition diagram

34


35/87

Chapter 17-35

Transaction and System Concepts (3)

Recovery manager keeps track of the following operations

(cont):

commit_transaction:This signals a successful endof

the transaction so that any changes (updates) executed

by the transaction can be safely committedto the

database and will not be undone.

rollback (or abort): This signals that the transaction

has ended unsuccessfully,so that any changes oreffects that the transaction may have applied to the

database must be undone.


36/87

Chapter 17-36


Recovery techniques use the following operators:

undo:Similar to rollback except that it applies to

a single operation rather than to a wholetransaction.

redo:This specifies that certain transaction

operationsmust be redoneto ensure that all the

operations of a committed transaction havebeen applied successfully to the database.


37/87

Chapter 17-37


The System Log Log or Journal: The log keeps track of all transaction

operations that affect the values of database items. This

information may be needed to permit recovery fromtransaction failures. The log is kept on disk, so it is notaffected by any type of failure except for disk orcatastrophic failure. In addition, the log is periodicallybacked up to archival storage (tape) to guard against

such catastrophic failures. T in the following discussion refers to a unique

transaction-idthat is generated automatically by thesystem and is used to identify each transaction:

Th S t L


38/87

The System Log Transactionid

System log Multiple record-type file

Log is kept on disk

Periodically backed up

Log records1. [start_transaction, T]2. [write_item, T,X,old_value,new_value]:

3. [read_item, T,X]

4. [commit,T]5. [abort,T]

6. [checkpoint]

Commit point of a transaction

38


39/87

How is the Log File Used? All permanent changes to data are recorded

Possible to undo changes to data After crash, search log backwards until find

last checkpoint

Know that beyond this point, effects of transaction

are permanently recorded

Need to either redoor undoeverything that

happened since last checkpoint

Undo: When transaction only partially completed

(before crash)

Redo: Transaction completed but we are unsure

whether data was written to disk

39


40/87

Example of a Transaction Log

TransID Table RowID column Before After

------- --------- ------ ------- ------ ------

100 **start**

100 EMPLOYEE 1005472 Salary 8000 8250

100 PROJECT 1423PRJ PrjRate 253 256

100 **end committed**

Chapter 17-40


41/87

A Sample SQL TransactionEXEC SQLWHENEVER SQLERROR GOTO UNDO;

EXEC SQLSET TRANSACTION

READ WRITE

DIAGONOSTIC SIZE 5

ISOLATION LEVEL SERIALIZABLE;

EXEC SQLINSERT INTO

EMPLOYEE(FNAME, LNAME, SSN, DNO, SALARY)VALUES (Ali, Al-Fares, 991004321, 2, 35000)

EXEC SQLUPDATE EMPLOYEE

SET SALARY = SALARY * 1.1 WHERE DNO = 2;

EXEC SQLCOMMIT;

GOTO END_T;UNDO: EXEC SQLROLLBACK;

END_T: ;

41


42/87

Checkpoints The point of synchronization between the database and

the transaction log file is called checkpoint.

Database recovery is performed using transaction log.

How far to go back in the transaction log to search in

case of failure.

Redoing transactions which are already Written to

databaseTime consuming & wasteful.

To find a point before which transactions are done

correctly and safelychecking point

In checkpoint technique, all buffers are force written to

secondary storage.

42


43/87

Checkpoint technique ... Is used to limit

the volume of log information

amount of searching and

subsequent processing that is needed to carry out on the

transaction log file.

Forcing a Checkpoint: Example The following statement forces a

checkpoint:

ALTER SYSTEM CHECKPOINT;

Enabling Resource Limits: Example This ALTER SYSTEM

statement dynamically enables resource limits:

ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;

43

Oracle CKPT


44/87

Oracle CKPT Oracle Database uses the following types of checkpoints (CKPT)

Consistent database shutdown

ALTER SYSTEM CHECKPOINT statementOnline redo log switch

ALTER DATABASE BEGIN BACKUP statement

A tablespace checkpoint is a set of data file checkpoints, one for

each data file in the tablespace. These checkpoints occur in a

variety of situations, including making a tablespace read-only or

taking it offline normal, shrinking a data file, or executing

ALTER TABLESPACE BEGIN BACKUP.

44

Desirable Properties of


45/87


Transactions

ACID properties1. AtomicityA transaction is an atomic unit of processing; it is either

performed in its entirety or not performed at all.

2. Consistency preservation

A transaction is consistency preserving if its completeexecution takes the database from one consistent state to

another

3. Isolation

The execution of a transaction should not be interfered with by

any other transactions executing concurrently4. Durability

The changes applied to the database by a committed

transaction must persist in the database. These changes must

not be lost because of any failure

45

D i bl P ti f


46/87


Transactions Atomicity

Responsibility of transaction processing and recovery

subsystems of the DBMS

Consistency

Preservation of consistency is the responsibility ofprogrammers

Each transaction is assumed to take database from one

consistent state to another consistent state

Isolation

Enforced by the concurrency control subsystem of theDBMS

Durability

Responsibility of the recovery subsystems of the DBMS

46


47/87

Transaction Processing

We have discussed that

Multiple transactions can be executed

concurrently by interleaving their operations

Schedule

Ordering of execution of operations from

various transactions T1, T2, , Tnis called a

schedule S

47


48/87

Schedules and Recoverability Definition of Schedule (or history)

Schedule S of n transactions T1,T2, , Tnis an ordering of the

operations of the transactionssubject to the constraint that, foreach transaction Tithatparticipates in S, the operations of

Tiin S must appear in the sameorder in which they occur in Ti.

48


49/87

Example of a Schedule

Transaction T1: r1(X); w1(X); r1(Y); w1(Y);c1

Transaction T2: r2(X); w2(X); c2

A schedule, S:

r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y); c1;

c2

49


50/87

Conflicts Two operations conflictif they satisfy ALL

three conditions:

1. they belong to different transactions AND

2. they access the same item AND

3. at least one is a write_item()operation

Example.:

S: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);

50

conflicts

S h d l f T ti


51/87

Schedules of Transactions Complete schedule

A schedule S of n transactions T1, T2, ..., Tn, is

said to be a complete schedule if the followingconditions hold:

The operations in S are exactly those operations in T1, T2,..., Tn including a commit or abort operation as the lastoperation for each transaction in the schedule.

For any pair of operations from the same transaction Ti,their order of appearance in Sis the same as their order ofappearance in Ti.

For any two conflicting operations, one of the two mustoccur before the other in the schedule

51


52/87

Serializability of Schedules

Serial Schedule

Non-serial schedule

Serializable schedule

Conflict-serializable schedule

View-serializable schedule

File Attached: Ch17-18doc

52


53/87

Chapter 17-53

Characterizing Schedules

based on Serializability (2)

Result equivalent: Two schedules are called

result equivalent if they produce the same final

state of the database.

Conflict equivalent: Two schedules are said to

be conflict equivalent if the order of any two

conflicting operations is the same in both

schedules. Conflict serializable: A schedule S is said to be

conflict serializable if it is conflict equivalent to

some serial schedule S.


54/87

54


55/87

Chapter 17-55



Being serializable is not the same as being

serial

Being serializable implies that the schedule is a

correct schedule.

It will leave the database in a consistent state.

The interleaving is appropriate and will result in a

state as if the transactions were serially executed, yet

will achieve efficiency due to concurrent execution.


56/87

Serializability of Schedules (Cont.)

Serial and Nonserial schedule

A schedule S is serial if, for every

transaction T participating in the schedule,

all the operations of T are executedconsecutively in the schedule; otherwise,

the schedule is called nonserial

Serializable scheduleA schedule S of n transactions is

serializable if it is equivalent to some

serial schedule of the same n transactions56


57/87

Serial Schedule

We consider transactions to be independent, so

serial schedule is correct

Based on C property in ACID

Furthermore, it does not matter whichtransaction is executed first, as long as every

transaction is executed in its entirety, from

beginning to end

Example

Assume X=90, Y=90, N=3, M=2, then result of

schedule S is X=89 and Y= 93

Same result if we start with T257

Why Do We Interleave Transactions?


58/87

Why Do We Interleave Transactions?

T1read_item(X);X:=X-N;

write_item(X);

read_item(Y);Y:=Y+N;

write_item(Y);

58

T2

read_item(X):

X:=X+M;write_item(X);

Could be a long wait

S is a serial scheduleno interleaving!

Schedule S

Another Sched le


59/87

Another Schedule

T1read_item(X);

X:=X-N;

write_item(X);

read_item(Y);

Y:=Y+N;write_item(Y);

59

T2

read_item(X):

X:=X+M;

write_item(X);

S is a non-serial schedule

T2 will be done faster but is the result correct?

Schedule S


60/87

Concurrent Executions

Serial execution is by far simplest methodto execute transactions

No extra work ensuring consistency

Inefficient! Reasons for concurrency:

Increased throughput

Reduces average response time Need concept of correct concurrent

execution

Using same X, Y, N, M values as before,

result of S is X=92 and Y=93 (not correct) 60


61/87

Yet Another ScheduleT1

read_item(X);

X:=X-N;

write_item(X);

read_item(Y);

Y:=Y+N;write_item(Y);

61

T2

read_item(X):

X:=X+M;

write_item(X);

S is a non-serial schedule

Produces same result as serial schedule S

Schedule S

Serializability


62/87

Serializability Assumption:Every serial schedule is correct

Goal: Find non-serialschedules which are alsocorrect

A schedule Sof ntransactions is serializable if it

is equivalent to some serial schedule of the

same ntransactions

When are two schedules equivalent?

Option 1: They lead to same result (result

equivalent) Option 2: The order of any two conflicting

operations is the same (conflict equivalent)

62


63/87

Result Equivalent Schedules Two schedules are result equivalent if they

produce the same final state of the database

Problem: May produce same result by accident!

63

S1read_item(X);

X:=X+10;

write_item(X);

S2read_item(X);

X:=X*1.1;

write_item(X);

Schedules S1 and S2 are result equivalent for X=100 but not in general


64/87

Conflict Equivalent Schedules

Two schedules are conflict equivalent, if

the order of any two conflicting operations

is the same in both schedules

64


65/87

Conflict Equivalence

T1read_item(A);

write_item(A);

read_item(B);

write_item(B);

65

T2

read_item(A):

write_item(A);

read_item(B);

write_item(B);

order mattersorder doesnt matter

order matters

Serial Schedule S1

order

doesnt matter

C fli t E i l


66/87

Conflict EquivalenceT1

read_item(A);

read_item(B);

write_item(A);

write_item(B);

66

T2

read_item(A):

write_item(A);

read_item(B);

write_item(B);S1 and S1 are conflict equivalent

(S1 produces the same result as S1)

Schedule S1

same order as in S1

same order as in S1

C fli t E i l


67/87

Conflict EquivalenceT1

read_item(A);

write_item(A);

read_item(B);

write_item(B);

67

T2

read_item(A):

write_item(A);

read_item(B);

write_item(B);

Schedule S1 is not conflict equivalent to S1

(produces a different result than S1)

Schedule S1

different order than in S1

different order than in S1

Conflict Serializable


68/87

Conflict Serializable Schedule S is conflict serializable if it is

conflict equivalent to some serialschedule S We can reorder the non-conflictingoperations to

improve efficiency

Non-conflicting operations:

Reads and writes from same transaction

Reads from different transactions

Reads and writes from different transactions on

different data items

Conflicting operations:

Reads and writes from different transactions on

same data item

68

Example


69/87

Example

T1read_item(X);

X:=X-N;

write_item(X);

read_item(Y);

Y:=Y+N;

write_item(Y);

69

T2

read_item(X);

X:=X+M;

write_item(X);

T1read_item(X);

X:=X-N;

write_item(X);

read_item(Y);

Y:=Y+N;

write_item(Y);

T2

read_item(X);X:=X+M;

write_item(X);

Schedule A Schedule B

B is conflict equivalent to A B is serializable

Test for Serializability


70/87

Test for Serializability Construct a directed graph,precedence graph,G = (V,

E)

V: set of all transactions participating in schedule

E: set of edges TiTjfor which one of the following holds:

Tiexecutes a write_item(X) before Tjexecutes read_item(X)

Tiexecutes a read_item(X) before Tjexecutes write_item(X)

Tiexecutes a write_item(X) before Tjexecutes write_item(X) An edge TiTj means that in any serial schedule

equivalent to S, Timust come before Tj

If G has a cycle, than S is not conflict serializable

If not, use topological sort to obtain serialiazableschedule (linear order consistent with precedence

order of graph)

70


71/87

Sample Schedule ST1

read_item(X);

write_item(X);

read_item(Y);

write_item(Y);

71

T2

read_item(Z);

read_item(Y);

write_item(Y);

read_item(X);

write_item(X);

T3

read_item(Y);read_item(Z);

write_item(Y);write_item(Z);


72/87

Precedence Graph for S

72

T1 T2

T3

X,Y

Y Y,Z

Equivalent Serial Schedule:

T3T1T2

(precedence order)

no cyclesS is serializable

FIGURE 17 8 (continued)


73/87

Chapter 17-73

FIGURE 17.8 (continued)

Another example of serializability testing. (b) Schedule E.



74/87


based on Serializability Being serializable is not the same as

being serial

Being serializable implies that the

schedule is a correct schedule.

It will leave the database in a consistent

state.

The interleaving is appropriate and will result

in a state as if the transactions were serially

executed, yet will achieve efficiency due to

concurrent execution. 74



75/87


based on Serializability

Serializability is hard to check.

Interleaving of operations occurs in an

operating system through some scheduler Difficult to determine before hand how the

operations in a schedule will be interleaved.

75



76/87


based on SerializabilityPractical approach: Come up with methods (protocols) to ensure

serializability.

Its not possible to determine when a schedule begins

and when it ends. Hence, we reduce the problem ofchecking the whole schedule to checking only a

committed projectof the schedule (i.e. operations from

only the committed transactions.)

Current approach used in most DBMSs: Concurrency control techniques

Examples

Two-phase locking technique

Timestamp ordering technique

76



77/87

Chapter 17-77



Serializability is hard to check.

Interleaving of operations occurs in an

operating system through some scheduler Difficult to determine beforehand how the

operations in a schedule will be interleaved.



78/87


based on Serializability View equivalence: A less restrictive definition of

equivalence of schedules

View serializability Definition of serializability based on view equivalence.

A schedule is view serializable if it is view equivalent to

a serial schedule.

78



79/87


based on SerializabilityTwo schedules are said to be view equivalentif the following three

conditions hold:

1. The same set of transactions participates in S and S, and S and S

include the same operations of those transactions.

2. For any operation Ri(X) of Tiin S, if the value of X read by theoperation has been written by an operation Wj(X) of Tj(or if it is the

original value of X before the schedule started), the same condition

must hold for the value of X read by operation Ri(X) of Tiin S.

3. If the operation Wk(Y) of Tkis the last operation to write item Y in S,

then Wk(Y) of Tkmust also be the last operation to write item Y inS.

79



80/87


based on SerializabilityThe premise behind view equivalence:

As long as each read operation of a transaction reads

the result of the same write operationin both schedules,

the write operations of each transaction must produce

the same results.

The view:the read operations are said to see the the

same viewin both schedules.

80



81/87


based on SerializabilityRelationship between view and conflict equivalence:

The two are same under constrained write assumption

which assumes that if T writes X, it is constrained by the

value of X it read; i.e., new X = f(old X)

Conflict serializability is stricterthan view serializability.

With unconstrained write (or blind write), a schedule that

is view serializable is not necessarily conflict serializable.

Any conflict serializable schedule is also view

serializable, but not vice versa.

81



82/87


based on SerializabilityRelationship between view and conflict equivalence

(cont):

Consider the following schedule of three transactions

T1: r1(X), w1(X); T2: w2(X); and T3: w3(X):

Schedule Sa: r1(X); w2(X); w1(X); w3(X); c1; c2; c3;

In Sa, the operations w2(X) and w3(X) are blind writes, since T1 and

T3 do not read the value of X.

Sa is view serializable, since it is view equivalent to the serial

schedule T1, T2, T3. However, Sa is not conflict serializable, since

it is not conflict equivalent to any serial schedule.

82

FIGURE 17.7Constructing the precedence graphs for schedulesA and Dfrom Figure 17.5 to

t t f fli t i li bilit ( ) P d h f i l h d l A (b)


83/87

Chapter 17-83

test for conflict serializability. (a) Precedence graph for serial scheduleA. (b)

Precedence graph for serial schedule B. (c) Precedence graph for schedule C

(not serializable). (d) Precedence graph for schedule D(serializable, equivalent

to scheduleA).

T ti S t i SQL


84/87

Transaction Support in SQL A single SQL statement is always considered

to be atomic There is no explicit Begin_Transaction

statement

SET TRANSACTIONstatement in SQL2 sets

the characteristics of a transaction Access mode

READ only or READ-WRITE

Diagnostic area size

Indicates the number of conditions that can be heldsimultaneously in the diagnostic area.

Isolation level READ UNCOMMITTED, READ COMMITTED,

REPEATABLE READ, SERIALIZABLE

84


85/87

85

Isolation Level

Type of Violation

Dirty

READ

Non-

Repeatable

READ

Phantom

READ

UNCOMMITTEDYes Yes Yes

READ

COMMITTEDNo Yes Yes

REPEATABLE

READNo No Yes

SERIALIZABLE No No No

A Sample SQL Transaction


86/87

A Sample SQL TransactionEXEC SQL WHENEVER SQLERROR GOTO UNDO;

EXEC SQL SET TRANSACTION

READ WRITE

DIAGONOSTIC SIZE 5

ISOLATION LEVEL SERIALIZABLE;

EXEC SQL INSERT INTO

EMPLOYEE(FNAME, LNAME, SSN, DNO, SALARY)VALUES (Ali, Al-Fares, 991004321, 2, 35000)

EXEC SQL UPDATE EMPLOYEE

SET SALARY = SALARY * 1.1 WHERE DNO = 2;

EXEC SQL COMMIT;

GOTO END_T;UNDO: EXEC SQL ROLLBACK;

END_T: ;

86

S


87/87

Summary

Introduction to transaction processing Transaction and system concepts

Desirable properties of transactions

Schedules and recoverability Serializability of schedules

Transaction support in SQL

Thank you

Lec 1 Transaction Processing Concepts

Documents

Transcript of Lec 1 Transaction Processing Concepts