Scribd
Upload
13 views16 pages

Exercise 5

Uploaded by

beomeo
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 views16 pages

Exercise 5

Uploaded by

beomeo
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/ 16

Exercise 6

Transactions
Isolation
Concurrency means trouble

 Several processes
manipulating the
same data at the
same time can lead
to inconsistencies
Transactions
 START TRANSACTION  Isolated: Different
transactions may not
 COMMIT/ROLLBACK interact with each
other.
 Durable: Effects of a
 Atomic: Either the transaction are not
whole transaction is lost in case of a
run, or nothing. system crash.
 Consistent: Database
constraints are
preserved.
Serializability
 If the outcome of a
number of
transactions is
equal to the
outcome of the
transactions
executed without
time overlap
To run transactions serially
 …would solve the problem…

 …but is often practically impossible

 Therefore we use different isolation


levels
Locks
Lock compatibility
 To achieve different levels
of isolation, you can use
locks
LOCK Write Read
 Shared (read) lock Write No No
Read No Yes
 Exclusive (write) lock

 Locks are put on relevant


parts of the data

 Lock requests are queued


Isolation 0 – read uncommitted
 Does not ask for read lock

 Thereforeit can read data that


another transaction has a write lock
on

 ”Dirty
reads” – data modified by
another transaction, but not yet
committed
Isolation 1 – read committed
 Asks for read lock,
but releases it
after reading

 ”Non-repeatable
reads” – the same
query can give
different results
Isolation 2 – repeatable read
 If a query has a T1 T2
WHERE clause SELECT *
FROM users
spanning a range, a WHERE age
read lock is acquired BETWEEN 10
only for the result, not AND 30;
the entire range (no INSERT INTO
users VALUES
range lock) ( 3, 'Bob', 27 );
COMMIT;
SELECT *
 The result can’t be FROM users
changed, but new WHERE age
data can be added – BETWEEN 10
AND 30;
so called ”Phantoms”
Isolation 3 - serializable
 No other transactions are allowed to
interact with the data

 Range locks are used

 All
locks collected are kept until after
COMMIT
None of this is of course true…

 …at least not in ORACLE


Different approaches
”Pessimistic” ”Optimistic”

 ”We’d better make  ”If something funny is


sure nothing funny is going on, we can take
going on” care of that later”

 Locks  Check before COMMIT


that everything is in
order, otherwise abort
Which is better?

 Optimistic
approach never blocks
concurrent transactions

 But if conflicts happen often, the cost


for aborting will be high
How to do it? (1
example)st

Timestamp ordering
 Read is only
 Every transaction allowed if Tt>Tw,
is given a otherwise abort
timestamp Tt – Set Tr=Tt

 Every object has  Write is only


two timestamps allowed if Tt>Tr ,
– Last read Tr
otherwise abort
– Set Tw=Tt
– Last write Tw
– SKIP write if Tt<Tw!
(Thomas write rule)
How to do it? example)(2 nd

Multiversion concurrency control


 Several timestamped versions of data exist

 If Tt>Tw the transaction can pick an older version


to read, and does not have to abort (p 940)

 ORACLE uses something called Snapshot


Isolation, based on MVCC

 A simple way to think of Oracle read consistency


is to imagine each user operating a private copy
of the database
Not even the locks are that
simple…

You might also like