Tema3

Bibliografía

Transacciones Distribuidas
Ricardo Jiménez Peris, Marta Patiño Martínez Distributed Systems Laboratory Universidad Politécnica de Madrid (UPM) http://lsd.ls.fi.upm.es/lsd/lsd.htm

• Libros generales sobre transacciones:
– Weikum, Vossen. Transactional Information Systems. MorganKaufmann. 2002. – Lewis, Bernstein, Kifer. Databases and Transaction Processing. AddisonWesley.2002. – Garcia-Molina, Ullman, Widom. Database Systems: The Complete Book. Prentice Hall, 2002. – Gray, Reuter. Transaction Processing: Concepts and Techniques. Morgan-Kaufmann, 1993. – Bernstein, Newcomer. Principles of Transaction Processing. MorganKaufmann, 1997. – Bernstein, Hadzilacos, Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. – Lynch, Merrit, Weihl,Fekete. Atomic Transactions. Morgan-Kaufmann Publishers, 1994.
2 Laboratorio de Sistemas Distribuidos, Universidad Politécnica de Madrid

_áw

_áw

Motivación
• Transferencia entre dos cuentas bancarias. Read A Fallo inocuo Write A-100 Fallo perjudicial Read B Write B+100 • ¿Qué ocurre si hay un fallo durante la transacción?
– Los fallos pueden dejar la BD inconsistente.

Motivación
•¿Qué ocurre si dos transferencias con alguna cuenta en común se ejecutan concurrentemente?
1

a=Read(A) a=Read(A) 2 if a >= 100 then if a >= 100 then Write(A,a-100) Write(A,a-100) b=Read(B) b=Read(B) 3 4 Write(B,b+100) Write(B,b+100) end if end if

3

Laboratorio de Sistemas Distribuidos, Universidad Politécnica de Madrid

_áw

4

Laboratorio de Sistemas Distribuidos, UniversidadPolitécnica de Madrid

_áw

Introducción
• Las transacciones se propusieron para simplificar la programación de las BDs. • Una transacción consiste en una secuencia de operaciones que se ejecuta de forma atómica (indivisible). • La atomicidad tiene dos aspectos: – Atomicidad de fallo: La transacción se hace en su totalidad (la transacción compromete) o no se hace (la transacción aborta). – Atomicidadde sincronización: Los estados intermedios de la transacción no se pueden observar.

Introducción
• El modelo de sistema tradicional para las transacciones se conoce como crash-recovery. • En este modelo los procesos acceden a memoria persistente (no volátil) que sobrevive a los fallos. • Los procesos fallan y se recuperan, pudiendo acceder a su memoria persistente para averiguar que hicieron enel pasado.

5

Laboratorio de Sistemas Distribuidos, Universidad Politécnica de Madrid

_áw

6

Laboratorio de Sistemas Distribuidos, Universidad Politécnica de Madrid

_áw

1

Introducción
• Las transacciones garantizan las propiedades ACID:
– Atomicity: Efecto todo (compromete) o nada (aborta). – Consistency: Corrección del programa. – Isolation: Serialidad (serializability),efecto equivalente a una ejecución secuencial. – Durability: Los efectos de una transacción comprometida perduran (no se pierden).
7 Laboratorio de Sistemas Distribuidos, Universidad Politécnica de Madrid

Implementación de las transacciones
• El aislamiento se garantiza mediante protocolos de control de concurrencia. • La atomicidad y durabilidad se garantizan mediante protocolos derecuperación.

_áw

8

Laboratorio de Sistemas Distribuidos, Universidad Politécnica de Madrid

_áw

Control de concurrencia
• La falta de aislamiento produce dos problemas: lecturas inconsistentes (dirty reads) y modificaciones perdidas (lost updates). • Las lecturas inconsistentes se producen por acceder a valores intermedios de una transacción. • Las modificaciones perdidas se producen pordos lecturas concurrentes del mismo dato por parte de dos transacciones y éste es actualizado por las dos transacciones.

Control de concurrencia: Modificaciones Perdidas
a.Deposit(200) bal= a.GetBalance() (1) a.SetBalance(bal+200) (3) a.SetBalance(bal+300) (4)
bal 500 (1) 500 (2) 700 (3) 800 (4) a 500 (0) bal

a.Deposit(300) bal= a.GetBalance() (2)

9

Laboratorio de Sistemas...