CONTROL DE LA CONCURRENCIA

META DE LAS TRANSACCIONES

La meta de las transacciones es asegurar que todos los objetos gestionados por un servidor permanecen en un estado consistente cuando dichos objetos son accedidos por mltiples transacciones y en presencia de cadas del servidor.

Administracion de Transacciones
Aislamiento (+ Consistencia) => Control de la concurrencia
Atomicidad + Durabilidad => Recuperacion

Como funcionan
Son usualmente activadas por solicitudes de los usuarios via SQL o otro Data Manipulation Languages (DML). Las transacciones accesan a la base de datos via operaciones de lectura o escritura
INSERT, UPDATE, DELETE, o SELECT . Pueden modificar valores de atributos en tablas, cambiar las estructura de la base de datos, etc El alcance lo define el usuario.

Una vez iniciada, la transaccion debe terminar con un COMMIT o un ROLLBACK.

COMMIT registra permanentemente el resultado de la transaccion en la base de datos cambiando la base de datos de un estado consistente a otro ROLLBACK deshace los efectos

Transacciones
Con xito
AbreTransaccin Operacin Operacin

Abortado por el cliente

AbreTransaccin Operacin Operacin

Abortado por el servidor

AbreTransaccin Operacin Operacin El servidor aborta la transaccin

Operacin CierraTransaccin

Operacin AbortaTransaccin

ERROR en la operacin informado al cliente

Estados de la transaccion
Una transaccion alcanza su punto commit cuando todas las operaciones que accesan a la base de datos son completadas y el resultado se ha registrado en el log. Graba entonces un [commit, <transaction-id>] y termina. BEGIN END COMMIT

active

partially committed
ROLLBACK ROLLBACK aborted

committed

READ , WRITE

terminated

Cuando el sistema falla, busca en el log file las entradas [start, <transaction-id>] Y su no encuentra entradas [commit, <transaction-id>] Entonces deshace todas las operaciones registradas [write, <transaction-id>, X,6 old_value, new_value]

Entradas en el log
[start, <transaction-id>]: el inicio de ejecucion de la transaccion identificada como transaction-id [read, <transaction-id>, X]: la transaccion identificada como transaction-id reads el valor del item X de la base de datos [write, <transaction-id>, X, old-value, newvalue]: la transaccion identificada como transaction-id cambia el valor de X de la base de datos de su viejo valor al nuevo [commit, <transaction-id>]: la transaccion transaction-id se completa y sus efectos se registran [rollback, <transaction-id>]: la transaccion transaction-id se aborta y sus resultados se deshacen
7

Procedure Credit ( trans_id INTEGER, accno INTEGER, bcode CHAR(6), amount NUMBER) old NUMBER; new NUMBER; begin SELECT balance INTO old FROM account WHERE no = accno and branch = bcode; new := old + amount; UPDATE account SET amount = new WHERE no = accno and branch = bcode; COMMIT; EXCEPTION WHEN FAILURE THEN ROLLBACK;

17

Otro ejemplo de transaccion

1: 2: 3: 4: 5: 6: 7: 8: 9: Begin_Transaction get (K1, K2, CHF) from terminal Select BALANCE Into S1 From ACCOUNT Where ACCOUNTNR = K1; S1 := S1 - CHF; Update ACCOUNT Set BALANCE = S1 Where ACCOUNTNR = K1; Select BALANCE Into S2 From ACCOUNT Where ACCOUNTNR = K2; S2 := S2 + CHF; Update ACCOUNT Set BALANCE = S2 Where ACCOUNTNR = K2; Insert Into BOOKING(ACCOUNTNR,DATE,AMOUNT,TEXT) Values (K1, today, -CHF, 'Transfer'); 10: Insert Into BOOKING(ACCOUNTNR,DATE,AMOUNT,TEXT) Values (K2, today, CHF, 'Transfer'); 12: If S1<0 Then Abort_Transaction 11: End_Transaction

Problemas
El sistema falla durante una transaccion
La base de datos queda en estado inconsistente solucion: recuperacion

Multiples transacciones se ejecutan al mismo tiempo

Otras aplicaciones tienen acceso a estados inconsistentes de la base de datos solucion: control de la concurrencia
9

Que pasa si no existe Control en la concurrencia

Las operaciones derivan anomalias Problemas
Actualizacion perdida Lectura sucia Lecturas inconsistentes

10

Actualizacion Perdida
T1, T2: deposita en cuenta acc1 Es serial?? (si o no) Es serializable ? (si o no + por que)
Transactions T1: read(acc1) acc1 := acc1 + 10 T2: read(acc1) acc1 := acc1 + 20 write(acc1) commit State acc1 20 20 40 30

write(acc1) commit

Cambio de T2 se pierde Plan "

R1(acc1) R2(acc1) W2(acc1) W1(acc1)
11

Lectura Sucia
T1: dos depsitos en cuenta acc1, T2: suma todas las cuentas
Transactions T1: read(acc1) acc1 := acc1 + 10 write(acc1) T2: State acc1 20 sum 0

T2 ve data sucia de T1 plan "

R1(acc1) W1(acc1) R2(acc1) W2(sum) W1(acc1)
12

acc1 := acc1 + 10 write(acc1) commit

... read(acc1) sum := sum + acc1 write(sum) commit

30 30 40

Lectura inconsistente
T1: le vearias veces de cuenta acc1, T2: deposita cuenta acc1
Transactions T1: read(acc1) T2: read(acc1) acc1 := acc1 + 20 write(acc1) commit read(acc1) sum := sum + acc1 write(sum) commit State acc1 20 20 40

40

T2 lee distintos valores de acc1 plan"

R1(acc1) R2(acc1) W2(acc1) R1(acc1) W1(sum)
13

Plan
Plan = un entrelazado de acciones (read/write) de un conjunto de transacciones, en el que el conjunto de acciones de cada una de las transacciones individuales estan en el orden original Plan completo = da el commit o aborta al final

14

Plan completo ..ejemplo

Transactions T1: read(acc1) Schedule T2: read1(acc1) read(acc1) acc1 := acc1 + 20 write(acc1) commit read(acc1) sum := sum + acc1 write(sum) commit read2(acc1) write2(acc1) commit2 read1(acc1) write1(sum) commit1

estado inicial de BD + plan estado final de BD

15

Plan Serial
Una transaccion a la vez, no hay entrelazos
T1: T2: read(acc1) acc1 := acc1 + 20 write(acc1) commit

read(acc1) read(acc1) sum := sum + acc1 write(sum) commit

Estado final es consistente (si las transacciones lo son) Planes seriales diferentes dan estados finales diferentes tambien
16

Plan serializable
Plan con transacciones entrelazadas que produce el mismo resultado que un plan serial buenos" planes Los ejemplos anteriores son de planes no serializables

17

Verificando la seriabilidad
Idea: cuales acciones pueden ser intrecambiadas en un plan? Los siguientes, no pueden, sin crear un conflicto (cambiar el resultado)
Accciones dentro de la misma transaccion Acciones en transacciones distintas sobre el mismo objeto si al menos una de esas operaciones es una operacion write

Tratar de transformar a un plan serial con intercambios crea un serializable

18

Conflictos
Acciones en conflicto: par de acciones sobre el mismo objeto desde distintas transacciones donde al menos una de ellas es un write Dos planes son equivalentes-en-conflicto si tienen los mismos conflictos Un plan es serializable-en-conflicto si es enconflicto-equivalente a un plan serial

19

ejemplo
Estan en conflicto:
T1:R(X), T2:W(X), T3:W(X)

No estan en conflicto:
T1:R(X), T2:R(X), T3:R(X) T1:R(X), T2:W(Y), T3:R(X)

ejemplo
Mismos conflictos, equivalentes-en-conflicto

T1 W1(x)

T2 R2(x)

T3

conflicto
R2(x) W2(y) W3(y) R3(z) W3(z)

T1 W1(x) W1(y) W1(z)

T2

T3

conflicto R2(x) W2(y) W3(y) R3(z) W3(z)

W1(y) W1(z) R3(z) W2(y) W3(y)

R2(x) W2(y) W3(y) R3(z) W3(y)

W3(y) W3(z)

Sconf

Sser

W3(z)

Serializable-en-conflicto

Plan serial
21

Graficamente
Nodo para cada transaccion Ti Una desde Ti a Tj si hay una accion de Ti que precede y esta en conflicto co una accion en Tj Teorema : Un plan es serializable-en-conflicto si su grafico es aciclico.

22

Ejemplo

T1 W1(x)

T2 R2(x)

T3

conflicto

R2(x) W2(y) W3(y) R3(z) W3(z) R3(z) W2(y) W3(y) W3(y) W3(z)

W1(y) W1(z)

T1

T2

T3

Grafico de seriabilidad

Sconf

23

ejemplo

Saquen el grafico de este plan..

solucion

Generar grafico

Generar grafico

Protocolos de control de la concurrencia