






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
An in-depth exploration of transactions, their execution, and the various properties and degrees of isolation. It covers topics such as concurrency transparency, failure transparency, characterization, formalization, atomicity, consistency, isolation, and durability. The document also includes examples of sql queries and transactions, termination of transactions, and the architecture of transaction processing.
Typology: Slides
1 / 11
This page cannot be seen from the preview
Don't miss anything!
8-
l concurrency transparency l failure transparency
Database in a consistent state
Database may be temporarily in an inconsistent state during execution
Begin Transaction
End Transaction
Execution of Transaction
Database in a consistent state
main() { … EXEC SQL UPDATE Project SET Budget = Budget * 1. WHERE Pname = `CAD/CAM’; EXEC SQL COMMIT RELEASE ; return (0); … }
8-
… main { … EXEC SQL BEGIN DECLARE SECTION ; char flight_no[6], customer_name[20]; char day; EXEC SQL END DECLARE SECTION ; scanf (flight_no, day, customer_name); EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = :flight_no AND DATE = :day; EXEC SQL INSERT INTO FC(FNO, DATE, CNAME, SPECIAL); VALUES (:flight_no,:day,:customer_name, null ); printf (“Reservation completed”); EXEC SQL COMMIT RELEASE ; return (0); }
8-
Let l oij ( x ) be some operation oj of transaction Ti operating on data item x , where oj ∈ {read,write} and oj is atomic l OSi = ∪ j oij l Ni ∈ {abort,commit} Transaction Ti is a partial order Ti = {Σ i , < i } where ∂ Σ i = OSi ∪ { Ni } ∑ For any two operations oij , oik ∈ OSi , if oij = R ( x ) and oik = W ( x ) for any data item x , then either oij < ioik or oik < ioij ∏ ∀ oij ∈ OSi , oij < i Ni
Read( x ) Read( y ) x ← x + y Write( x ) Commit
Σ = { R ( x ), R ( y ), W ( x ), C } < = {( R ( x ), W ( x )), ( R ( y ), W ( x )), ( W ( x ), C ), ( R ( x ), C ), ( R ( y ), C )}
8-
< = {( R ( x ), W ( x )), ( R ( y ), W ( x )), ( R ( x ), C ), ( R ( y ), C ), ( W ( x ), C )}
R ( x )
C
R ( y )
W ( x )
l all or nothing
l no violation of integrity constraints
l concurrent changes invisible ⇒ serializable
l committed updates persist
8-
l If several transactions are executed concurrently, the results must be the same as if they were executed serially in some order.
l An incomplete transaction cannot reveal its results to other transactions before its commitment. l Necessary to avoid cascading aborts.
T 1 : Read( x ) T 2 : Read( x ) x ← x + 1 x ← x + 1 Write( x ) Write( x ) Commit Commit
T 1 : Read( x ) T 1 : Read( x ) T 1 : x ← x + 1 T 1 : x ← x + 1 T 1 : Write( x ) T 2 : Read( x ) T 1 : Commit T 1 : Write( x ) T 2 : Read( x ) T 2 : x ← x + 1 T 2 : x ← x + 1 T 2 : Write( x ) T 2 : Write( x ) T 1 : Commit T 2 : Commit T 2 : Commit
8-
l Transaction T does not overwrite dirty data of other transactions l Dirty data refers to data values that have been updated by a transaction prior to its commitment
l T does not overwrite dirty data of other transactions l T does not commit any writes before EOT
l T does not overwrite dirty data of other transactions l T does not commit any writes before EOT l T does not read dirty data from other transactions
l T does not overwrite dirty data of other transactions l T does not commit any writes before EOT l T does not read dirty data from other transactions l Other transactions do not dirty any data read by T before T completes_._
8-
n Once a transaction commits, the system must guarantee that the results of its operations will never be lost, in spite of subsequent failures.
n Database recovery
n Atomic and reliable execution in the presence of failures
n Correct execution in the presence of multiple user accesses
n Correct management of replicas (if they support it)
8-
Scheduling/ Descheduling Requests
Transaction Manager (TM)
Transaction Monitor
Begin_transaction, Read, Write, Commit, Abort
To execution engine
Results
Scheduler (SC)
Begin_Transaction, Read, Write, Abort, EOT
Results & User Notifications
Scheduled Operations Results
Results
…
Read, Write, Abort, EOT
User Application
User Application
Transaction Manager (TM)
Scheduler (SC)
Recovery Manager (RM)