Ús de bases de dades

PAC 2: Accés concurrent a bases de dades

Pregunta 1​ (50 % puntuació)

Enunciat

Sigui un SGBD ​sense cap mecanisme de control de concurrència​, i suposem que es produeix
l’horari que es mostra a la pàgina següent (on R=lectura; RU=lectura amb intenció d’actualització,
W=escriptura; les accions s’han numerat per facilitar la seva referència).

Es demana, argumentant ​breument​ la vostra resposta:

1. Digueu si hi ha interferències a l’horari anterior, quines, entre quines transaccions i per quins
grànuls.
2. En cas d’haver trobat interferències a l’horari anterior, indiqueu quin és el nivell d’aïllament
mínim de l’SQL estàndard que caldria per evitar cada una d’elles per separat. Quin seria el
nivell mínim d’aïllament si les volguéssim evitar totes simultàniament?
3. És recuperable l’horari anterior? Digueu quins són els horaris seriables equivalents.
4. Apliqueu un mecanisme de control de concurrència basat en reserves S, X i on les transaccions
treballen amb un nivell d’aïllament de R ​ EAD COMMITTED​. Com quedaria l’horari? S'eviten les
interferències de l'horari inicial? Quin és l’horari serial equivalent?
5. Apliqueu un mecanisme de control de concurrència basat en reserves S, X i on les transaccions
treballen amb un nivell d’aïllament de R ​ EPEATABLE READ​. Com quedaria l’horari? S'eviten les
interferències de l'horari inicial? Hi ha algun horari serial equivalent?

Nota: És possible que als apartats 4 i 5, com a conseqüència d’aplicar les reserves indicades, puguin
existir diferents propostes de solució igualment vàlides depenent de l’ordre d’execució de les
operacions de les transaccions.

Criteris d’avaluació

● Totes les preguntes tenen el mateix pes.

● ​Les preguntes no contestades no penalitzen.

● Es valorarà la qualitat de la resposta en relació als continguts dels mòduls didàctics, i el fet de
no entrar en contradiccions en les explicacions.
● S'han de justificar les respostes per aconseguir la puntuació màxima a tots els apartats.
● Les respostes no argumentades es consideraran com a no contestades​.

1
#Acc T1 T2 T3

10 R(A)

20 RU(B)

30 RU(B)

40 W(B)

50 W(B)

60 RU(A)

70 W(A)

80 RU(D)

90 W(D)

100 R(C)

110 RU(C)

120 W(C)

130 R(B)

140 R(D)

150 RU(D)

160 W(D)

170 RU(E)

180 W(E)

190 COMMIT

200 COMMIT

210 COMMIT

2
3
Solució

1. A l’horari proposat hi trobem les interferències

Actualització perduda ​entre T2 i T3, grànul B
Lectura no confirmada​ entre T2 i T3, grànul D
Anàlisi inconsistent​ entre T1 i T2, grànuls A i C

#Acc T1 T2 T3

10 R(A)

20 RU(B)

30 RU(B)

40 W(B)

50 W(B)

60 RU(A)

70 W(A)

80 RU(D)

90 W(D)

100 R(C)

110 RU(C)

120 W(C)

130 R(B)

140 R(D)

150 RU(D)

160 W(D)

170 RU(E)

180 W(E)

190 COMMIT

200 COMMIT

210 COMMIT

4
2. Per evitar les interferències trobades, ens calen els nivells mínims següents:
Actualització perduda ​READ UNCOMMITTED​,
Lectura no confirmada ​READ COMMITTED​,
Anàlisi inconsistent ​REPEATABLE READ
Per evitar totes les interferències a la vegada, ens hauríem de quedar amb el nivell més
restrictiu, és a dir, ​REPEATABLE READ​.

3. L'horari proposat no és recuperable, ja que, per exemple, T2 a l'acció 140 llegeix el grànul D,
prèviament escrit per T3 a l'acció 90, i T2 acaba la seva execució confirmant abans que T3.

No hi ha cap horari serial equivalent ja que l'horari proposat no és seriable degut a que hi ha
interferències.

4. Amb un nivell d’aïllament ​READ COMMITTED​, l’horari queda de la manera següent:

#Acc T1 T2 T3

10 LOCK(A,S)

20 R(A)

30 UNLOCK(A,S)

40 LOCK(B,X)

50 RU(B)

60 LOCK(B,X)

70 W(B)

80 LOCK(A,X)

90 RU(A)

100 W(A)

110 LOCK(C,S)

120 R(C)

130 UNLOCK(C,S)

140 LOCK(C,X)

150 RU(C)

160 W(C)

5
 170 LOCK(D,S)

180 R(D)

190 UNLOCK(D,S)

200 LOCK(E,X)

210 RU(E)

220 W(E)

230 COMMIT
UNLOCK(A)
UNLOCK(B)

240 RU(B)

250 W(B)

260 LOCK(D,X)

270 RU(D)

280 W(D)

290 R(B)

300 RU(D)

310 W(D)

320 COMMIT
UNLOCK(B)
UNLOCK(D)

330 COMMIT
UNLOCK(C)
UNLOCK(E)

Després de COMMIT de T2, s’ha triat continuar amb la transacció T3, encara que podria haver
continuat T1.

En relació a les interferències que tenia l’horari original podem veure com amb READ
COMMITTED s'eviten les interferències d'actualització perduda i de lectura no confirmada, però
segueix apareixent la interferència d'anàlisi inconsistent.

Donat que l’horari encara té interferències, no existeix cap horari serial que doni resultats
equivalents a l’horari que s’ha obtingut, malgrat l’ús de reserves.

5. Amb un nivell d’aïllament ​REPEATABLE READ​, l’horari queda tal com s’indica a continuació:

6
#Acc T1 T2 T3

10 LOCK(A,S)

20 R(A)

30 LOCK(B,X)

40 RU(B)

50 LOCK(B,X)

60 W(B)

70 LOCK(A,X)

80 LOCK(C,X)

90 RU(C)

100 W(C)

110 LOCK(E,X)

120 RU(E)

130 W(E)

140 COMMIT
UNLOCK(A)
UNLOCK(C)
UNLOCK(E)

150 RU(A)

160 W(A)

170 LOCK(C,S)

180 R(C)

190 LOCK(D,S)

190 R(D)

200 COMMIT
UNLOCK(A)
UNLOCK(B)
UNLOCK(C)
UNLOCK(D)

210 RU(B)

7
 220 W(B)

230 LOCK(D,X)

240 RU(D)

250 W(D)

260 R(B)

270 RU(D)

280 W(D)

290 COMMIT
UNLOCK(B)
UNLOCK(D)

Aquest horari ha acabat sense abraçades mortals i gràcies al nivell d’aïllament aplicat està
lliure d’interferències. Per tant, existeix un horari serial que dona resultats equivalents a l’horari
obtingut. L’horari serial equivalent seria T1;T2;T3.

Pregunta 2 (30% puntuació)

Enunciat

Donades les taules que es mostren a continuació (extretes de la base de dades de la pràctica, amb
algunes simplificacions), suposem que volem executar diverses transaccions. Aquestes transaccions
executaran les peticions següents:

T1 T2 T3

SELECT * UPDATE MUSICIAN SENTÈNCIA SQL

FROM MUSICIAN SET gender = 'M'
WHERE nationality = 'English'’; WHERE nationality = 'English';

SELECT * SELECT *
FROM MUSICIAN FROM MUSICIAN
WHERE nationality = 'English'’; WHERE nationality = 'American';

UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality =
'American';

COMMIT COMMIT COMMIT

8
 MUSICIAN

id name birth_date nationality gender

2 Mick Jagger 26-07-1943 English F

8 Kirk Hammet 18-11-1962 American F

Suposant que el grànul és la fila i que l’SGBD ​no implementa cap mecanisme de control de
concurrència​, responeu a les preguntes següents (heu de raonar breument les vostres respostes).
Cada apartat s’ha de respondre de forma independent, obviant les respostes donades als apartats
previs.

1. Proposeu, si és possible, un horari que incorpori totes les sentències SQL de T1 i T2 i que
contingui una interferència de tipus anàlisi inconsistent.

2. Proposeu un horari, si és possible, que incorpori totes les sentències SQL de T1 i T2, que no
contingui cap interferència, però que sigui no recuperable.

3. Proposeu, si és possible, un horari i una sentència SQL a executar per T3 que causi una
interferència de tipus fantasma entre T1 i T3 (que causi que aparegui un fantasma).

Criteris d’avaluació

● Totes les preguntes tenen el mateix pes.

● Les preguntes no contestades no penalitzen.
● Es valorarà la qualitat de la resposta en relació als continguts dels mòduls didàctics, i el fet de
no entrar en contradiccions en les explicacions.
● S'han de justificar les respostes per aconseguir la puntuació màxima a tots els apartats.
● Les respostes no argumentades es consideraran com a no contestades.

​Solució

1) A continuació proposem un horari per T1 i T2 que verifica les condicions indicades a l’enunciat:

#acc T1 T2

10 SELECT *
FROM MUSICIAN
WHERE nationality = 'English'’;

9
 20 SELECT *
FROM MUSICIAN
WHERE nationality = 'English'’;

30 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality = 'English';

40 SELECT *
FROM MUSICIAN
WHERE nationality = 'American';

50 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality =
'American';

60 COMMIT

70 COMMIT

2) A continuació proposem un horari per T1 i T2 que verifica les condicions indicades a l’enunciat:

#acc T1 T2

10 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality = 'English';

20 SELECT *
FROM MUSICIAN
WHERE nationality = 'American';

30 SELECT *
FROM MUSICIAN
WHERE nationality =
'English'’;

40 SELECT *
FROM MUSICIAN
WHERE nationality =
'English'’;

50 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality =
'American';

60 COMMIT

10
 70 COMMIT

L’horari no presenta interferències, de fet dona els mateixos resultats que l’horari serial T2; T1,
però no és un horari recuperable. T1 llegeix dades pendents de confirmació a les accions 30 i
40 (en concret veu la modificació efectuada per T2 a l’acció 10), i T1 acaba la seva execució
abans que T2.

Un altre possible solució seria la següent:

#acc T1 T2

10 SELECT *
FROM MUSICIAN
WHERE nationality =
'English'’;

20 SELECT *
FROM MUSICIAN
WHERE nationality =
'English'’;

30 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality =
'American';

40 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality = 'English';

50 SELECT *
FROM MUSICIAN
WHERE nationality = 'American';

60 COMMIT

70 COMMIT

3) A continuació proposem un horari per T1 i T3 que verifica les condicions indicades a l’enunciat:

#acc T1 T3

10 SELECT *
FROM MUSICIAN
WHERE nationality =
'English'’;

11
 20 UPDATE MUSICIAN
SET nationality = 'English';

30 SELECT *
FROM MUSICIAN
WHERE nationality =
'English'’;

40 UPDATE MUSICIAN
SET gender = 'M'
WHERE nationality =
'American';

50 COMMIT

60 COMMIT

La transacció T1 a l’instant 10 fa la lectura dels músics de nacionalitat anglesa, on només

apareixeran les dades del músic amb id=2. Però en paral·lel T3 està canviant la nacionalitat del
músic amb id=8. A l’instant 30 T1 fa una lectura on apareix un fantasma, ja que a banda de les
dades del músic amb id=2 que ja apareixien a la primera lectura, també apareixen les dades
del músic amb id=8 després de que T3 hagi actualitzat la seva nacionalitat.

De fet, T3 també podria haver executat en el mateix instant una sentència INSERT enlloc
d’UPDATE sobre la taula ​MUSICIAN​ on el músic fos de nacionalitat anglesa.

Pregunta 3 (20% puntuació)

Enunciat

● Utilitzant la taula següent:

CREATE TABLE employee(

id SMALLINT PRIMARY KEY,

name VARCHAR(255));

i les següents dades inicials:

INSERT INTO employee VALUES( 1, 'Jordi Cruz');

Executeu aquest horari amb PostgreSQL (utilitzeu dues finestres per simular les dues
transaccions concurrents) i expliqueu per què T2 no es bloqueja a l'hora d'executar el SELECT.

12
 #acc T1 T2

10 START TRANSACTION;

20 START TRANSACTION;

30 UPDATE employee SET

name = 'Pepe Rodriguez'
WHERE id = 1

40 SELECT * FROM employee WHERE

id = 1

50 COMMIT

60 COMMIT

● Digueu si les afirmacions següents són certes o falses. Raoneu breument la vostra resposta.

1) Una abraçada mortal necessita d'almenys 3 transaccions concurrents.

2) Una transacció amb nivell d'aïllament de READ UNCOMMITTED pot generar un horari
de reserves que sigui PR2F estricte.

Criteris d’avaluació

● Totes les preguntes tenen el mateix pes.

● Les preguntes no contestades no penalitzen.
● Les respostes sense argumentació no seran avaluades.
● Es valorarà la qualitat de la resposta en relació als continguts dels mòduls didàctics, i el fet de
no entrar en contradiccions en les explicacions.

​Solució

● El motiu pel qual T2 no bloqueja és perquè PosgreSQL internament utiliza MVCC (​Multiversion
concurrency control)​ . En l'MVCC, les accions de només lectura (R(G)), mai generen reserves ni
tampoc veuen mai bloquejada l'execució.

1) Fals​. Es pot tenir una abraçada mortal amb dues transaccions.

El següent horari provoca una abraçada mortal fins i tot si utilitzem un nivell d'aïllament igual o
superior a READ COMMITTED.

13
 #Acc T1 T2

10 RU(C)

20 W(C)

30 RU(B)

40 W(B)

50 R(B)

60 R(C)

70 COMMIT

80 COMMIT

Aplicant reserves, veiem que tant T1 com T2 bloquegen la seva execució.

#Acc T1 T2

10 LOCK(C,X)

20 RU(C)

30 LOCK(B,X)

40 RU(B)

50 W(B)

LOCK(B,S)

60 LOCK(C,S)

2) Cert​. Qualsevol transacció que només tingui operacions d'escriptura generarà un horari de
reserves PR2F estricte.

14