Transaction and - PowerPoint Presentation

Slide1

Transaction and concurrency controll

Chapter 13

“Distributed Systems: Concepts and Design”Coulouris, Dollimore, Kindberg

Hanna

Björling,

Stina Fröjd & Liv SundmanSlide2

TransactionA transaction is a point where there is interaction with the database

A transaction is generally atomicThe state of the transaction being done is not visible. If it is not done completely, any changes it made will be undone. This is known as rollbackSlide3

TransactionIt’s common to talk about transactions in banking systems

Ex: A transfer between accounts. The money should be transferred as well as withdrawnTo make sure both things are done concurrency control is usedSlide4

Concurrency control

Concurrency – multiple users want to access the same data at the same timeConcurrency control (CC) ensures that correct results for parallel operations are generatedCC provides rules, methods, design methodologies and theories to maintain the consistency of components operating simultaneously while interacting with the same objectSlide5

Why concurrency control?

Concurrency control is needed because there are a lot of things that can go wrongEach transaction itself can be okay, but the concurrency generates problems such as:

The lost update problemThe dirty read problemThe incorrect summary problemSlide6

Read and write conflicts

Figur 13.9Slide7

Three methodsThere are many methods for concurrency control

The main methods are:LocksOptimistic concurrency controlTimestamp orderingSlide8

LocksLocks are used to order transactions that access the same objects according to the order of arrival of their operations at the objects

Mechanism for enforcing limits on access to the objectIf the access to the object is locked other users have to wait until it’s unlockedSlide9

Lock compability

Figur 13.15Slide10

A problem with lockThe use of locks can lead to deadlocks

Ex: Two transactions are waiting and each is dependent on the other to release a lock so it can resume

BA

Waits for

Held by

Held by

T

U

U

T

Waits for

Figur 13.20Slide11

Optimistic concurrency control Optimistic concurrency control (OCC) is based on the assumption that two transactions won’t occur at the same time

OCC is generally used in environments with low data contentionSlide12

OCC phasesBegin

Working phaseValidation phase

Update phaseSlide13

OCC phasesBegin

: Record a timestamp marking the transaction's beginningWorking phase: Read and write database values to a copy of the transaction which is not yet bound to the object. Several different transactions of this type may coexistSlide14

OCC phasesValidate phase

: Controls if the transaction conflicts with another transaction on the same object Update phase: Committed: If there is no conflict, make all changes part of the official state of the database

Aborted: If there is a conflict, resolve it, typically by aborting the transaction, although other resolution schemes are possibleSlide15

TimestampWhenever a transaction starts, it is given a timestamp

The timestamp tells in which order that the transactions are supposed to be applied inThe transaction with the earliest timestamp is executed firstEvery object in the database has a read timestamp and a write timestampSlide16

Major goalsSerializability

RecoverabilityDistributionSlide17

SerializabilityThe goal with serializability

is that the result of the parallel transactions is the same as if though the transactions were preformed seriallySlide18

RecoverabilityRecoverability means that committed transactions do not read data written by aborted transactionsSlide19

distributionDistributed serializability

The serializability concept Commitment Ordering allows to effectively achieve global

serializability across multiple Database Systems, that may use different concurrency control mechanisms.Slide20

Questions?Slide21

Thank you,Nu är det slut!Slide22