Scribd
Upload
11 views

SQL - Transactions

Uploaded by

pbecic
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
11 views

SQL - Transactions

Uploaded by

pbecic
Copyright
© © All Rights Reserved
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