Scribd
Upload
13 views

SQL - Transactions

Uploaded by

pbecic
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
13 views

SQL - Transactions

Uploaded by

pbecic
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

SQL: Transactions

Introduction to Databases
CompSci 316 Fall 2014
2

Announcements (Thu., Oct. 16)


• Project Milestone #1 due today
• Homework #1 grades/feedback released on Sakai
• Midterm grades and sample solution to be posted
on Sakai by Tuesday
3

Transactions
• A transaction is a sequence of database operations
with the following properties (ACID):
• Atomic: Operations of a transaction are executed all-or-
nothing, and are never left “half-done”
• Consistency: Assume all database constraints are
satisfied at the start of a transaction, they should remain
satisfied at the end of the transaction
• Isolation: Transactions must behave as if they were
executed in complete isolation from each other
• Durability: If the DBMS crashes after a transaction
commits, all effects of the transaction must remain in
the database when DBMS comes back up
4

SQL transactions
• A transaction is automatically started when a user
executes an SQL statement
• Subsequent statements in the same session are
executed as part of this transaction
• Statements see changes made by earlier ones in the
same transaction
• Statements in other concurrently running transactions
do not
• command commits the transaction
• Its effects are made final and visible to subsequent
transactions
• command aborts the transaction
• Its effects are undone
5

Fine prints
• Schema operations (e.g., )
implicitly commit the current transaction
• Because it is often difficult to undo a schema operation
• Many DBMS support an feature,
which automatically commits every single
statement
• You can turn it on/off through the API
• Examples later in this lecture
• For PostgreSQL:
• command-line processor turns it on by default
• You can turn it off at the prompt by typing:
6

Atomicity
• Partial effects of a transaction must be undone
when
• User explicitly aborts the transaction using
• E.g., application asks for user confirmation in the last step and
issues or depending on the response
• The DBMS crashes before a transaction commits
• Partial effects of a modification statement must be
undone when any constraint is violated
• Usually only this statement is rolled back; the
transaction continues
• How is atomicity achieved?
• Logging (to support undo)
7

Durability
• DBMS accesses data on stable storage by bringing
data into memory
• Effects of committed transactions must survive
DBMS crashes
• How is durability achieved?
• Forcing all changes to disk at the end of every
transaction?
• Too expensive
• Logging (to support redo)
8

Consistency
• Consistency of the database is guaranteed by
constraints and triggers declared in the database
and/or transactions themselves
• Whenever inconsistency arises, abort the statement or
transaction, or (with deferred constraint checking or
application-enforced constraints) fix the inconsistency
within the transaction
9

Isolation
• Transactions must appear to be executed in a serial
schedule (with no interleaving operations)
• For performance, DBMS executes transactions
using a serializable schedule
• In this schedule, operations from different transactions
can interleave and execute concurrently
• But the schedule is guaranteed to produce the same
effects as a serial schedule
• How is isolation achieved?
• Locking, multi-version concurrency control, etc.
10

SQL isolation levels


• Strongest isolation level:
• Complete isolation
• Weaker isolation levels: ,
,
• Increase performance by eliminating overhead and
allowing higher degrees of concurrency
• Trade-off: sometimes you get the “wrong” answer
11

• Can read “dirty” data


• A data item is dirty if it is written by an uncommitted
transaction
• Problem: What if the transaction that wrote the
dirty data eventually aborts?
• Example: wrong average
•
!
" #$%%
&' ()* " + , -./ 0
1 !,
,
,
12

• No dirty reads, but non-repeatable reads possible


• Reading the same data item twice can produce different
results
• Example: different averages
•
-./ 0
1 !,
!
" #$%%
&' " + ,
,
-./ 0
1 !,
,
13

• Reads are repeatable, but may see phantoms


• Example: different average (still!)
•
-./ 0
1 !,
!
- /23%4 5 4
#4 #$ 0,
,
-./ 0
1 !,
,
14

Summary of SQL isolation levels


Isolation level/anomaly Dirty reads Non-repeatable reads Phantoms
Possible Possible Possible
Impossible Possible Possible
Impossible Impossible Possible
Impossible Impossible Impossible

• Syntax: At the beginning of a transaction,


-
isolation_level [ 6| & ]
• can only be 6

• PostgreSQL defaults to
15

Transactions in programming
Using 7 8 9 as an example:
8 55 " 78 9 $8 55 8 /*:5;< " : ! 0
8 55$ = ) 5/) ; ) 5= > " 4
! ;*7= 5 7"1; 4
;( 8 <<) " !( 0
•) ; ) 5= > defaults to
• ! ;*= 5 7 defaults to 1;
• ;( 8 <<) defaults to 1;
• When ;( 8 <<) is 1; , commit/abort
current transaction as follows:
8 55$8 <<) /0
8 55$! :;8?/0
16

ANSI isolation levels are lock-based


•
• Short-duration locks: lock, access, release immediately
•
• Long-duration write locks: do not release write locks
until commit
•
• Long-duration locks on all data items accessed
•
• Lock ranges to prevent insertion as well
17

Isolation levels not based on locks?


Snapshot isolation in Oracle
• Based on multiversion concurrency control
• Used in Oracle, PostgreSQL, MS SQL Server, etc.
• How it works
• Transaction performs its operations on a private
snapshot of the database taken at the start of
• can commit only if it does not write any data that
has been also written by a transaction committed
after the start of
• Avoids all ANSI anomalies
• But is NOT equivalent to
because of write skew anomaly
18

Write skew example


• Constraint: combined balance + ≥ 0
• = 100, = 100
• T1 checks + – 200 ≥ 0, and then proceeds to
withdraw 200 from
• T2 checks + – 200 ≥ 0, and then proceeds to
withdraw 200 from
• Possible under snapshot isolation because the
writes (to and to ) do not conflict
• But + = −200 < 0 afterwards!
19

Bottom line
• Group reads and dependent writes into a
transaction in your applications
• E.g., enrolling a class, booking a ticket

• Anything less than is potentially very


dangerous
• Use only when performance is critical
• 6 makes weaker isolation levels a bit safer

You might also like