Concurrencia y transacciones - script
From Ibbddunq
| Line 34: | Line 34: | ||
=== propiedades ACID === | === propiedades ACID === | ||
| - | * Atomicidad: la garantiza el motor. Las aplicaciones deben la responsabilidad de '''demarcar''' transacciones. | + | * Atomicidad: la garantiza el motor. Las aplicaciones deben la responsabilidad de '''demarcar''' transacciones (ya veremos qué es eso). |
| - | * Consistencia: la debe garantizar uno haciendo operaciones correctas en cada transacción. P.ej. | + | * Consistencia: la debe garantizar uno (el que envía las sentencias SQL al motor) haciendo operaciones correctas en cada transacción. Las cuestiones de consistencia más semántica no pueden resolverse mediante restricciones, hay que hacer las cosas bien. P.ej. |
| - | ** si | + | ** si tengo un sistema de stock en distintos depósitos y muevo mercadería de uno a otro, tengo que hacer dos operaciones, si hago una sola está mal. |
| - | ** si agrego una | + | ** si agrego una factura por un importe, debo agregar ítems que justifiquen ese importe. |
* Durabilidad: la garantiza el motor. | * Durabilidad: la garantiza el motor. | ||
| - | * Aislamiento: necesita un tratamiento particular. | + | * Aislamiento: necesita un tratamiento particular, de eso vamos a hablar bastante. |
=== demarcación === | === demarcación === | ||
| - | + | Contar la idea de demarcación, se puede hacer pensando desde el motor, me llegan sentencias SQL de un usuario, cómo sé cuándo termina una transaccion y empieza otra. P.ej. en el sistema de la biblioteca, un usuario se lleva dos libros, después otro se lleva tres y devuelve uno, después se agrega un nuevo socio que retira un libro, etc. | |
| + | === costo de la serialización === | ||
| + | Costo del aislamiento si lo llevo a serialización, necesidad de manejarlo a mano. | ||
| + | |||
| + | Pensar en el sistema de carga on-line de declaraciones de Ganancias de la AFIP el día que se vence. Ahí es muy difícil que tengas problemas de concurrencia, porque mi declaración no se pisa con la tuya. Entonces la serialización no trae ventajas y sí hace impracticable a un sistema con una BD relacional atrás. | ||
| - | |||
== Anomalías de concurrencia en el manejo con BDs == | == Anomalías de concurrencia en el manejo con BDs == | ||
| + | ... to be continued ... falta un montonazo por poner | ||
Revision as of 18:21, 28 August 2009
Contents |
Intro a problemática de concurrencia
Operaciones que se ejecutan en forma concurrente
Ejemplo: un tablero con llaves maestras, cada una abre varias cerraduras. Yo tengo que abrir varias cerraduras, ¿qué pasa si por las dudas me llevo todo el tablero? ¿Qué pasa si otra persona tiene que abrir una cerradura para la que sirve solamente una llave que me llevé yo?
Schedule
Schedule, schedules "buenos" y "malos". En el caso de las llaves es fácil, hay solamente dos acciones posibles. Armar un schedule bueno y uno malo. Operaciones de BD hay varias.
Recurso y deadlock
Concepto de recurso, necesidad de garantizar el acceso exclusivo a un recurso y de liberarlo luego, colas de espera. En nuestro caso está claro, los recursos son las llaves.
Si una persona necesita varios recursos, debe esperar que le lleguen todos. De acá llegar al concepto de deadlock.
Carga
Es la medida de concurrencia de cualquier situación concurrente. P.ej. cuanto más carga, más posibilidad de espera, y a menos que lo manejemos hábilmente, mayor probabilidad de deadlock.
Concepto de transacción
en las BD y en la vida
Ejemplos de la vida: pago con tarjeta, intercambio de rehenes.
Ejemplos de BD: si voy a cargar una factura (vg ej de productos clientes y facturas (1) guía SQL avanzado), tengo que cargar los ítems. Si en una BD de una biblioteca (ej. Biblioteca (4) guía SQL avanzado) una persona en el mismo acto se lleva dos libros y devuelve tres, eso hay que registrarlo transaccionalmente. Entender qué quiere decir "transaccionalmente".
Hablar de inteacción entre un SI y una BD.
propiedades ACID
- Atomicidad: la garantiza el motor. Las aplicaciones deben la responsabilidad de demarcar transacciones (ya veremos qué es eso).
- Consistencia: la debe garantizar uno (el que envía las sentencias SQL al motor) haciendo operaciones correctas en cada transacción. Las cuestiones de consistencia más semántica no pueden resolverse mediante restricciones, hay que hacer las cosas bien. P.ej.
- si tengo un sistema de stock en distintos depósitos y muevo mercadería de uno a otro, tengo que hacer dos operaciones, si hago una sola está mal.
- si agrego una factura por un importe, debo agregar ítems que justifiquen ese importe.
- Durabilidad: la garantiza el motor.
- Aislamiento: necesita un tratamiento particular, de eso vamos a hablar bastante.
demarcación
Contar la idea de demarcación, se puede hacer pensando desde el motor, me llegan sentencias SQL de un usuario, cómo sé cuándo termina una transaccion y empieza otra. P.ej. en el sistema de la biblioteca, un usuario se lleva dos libros, después otro se lleva tres y devuelve uno, después se agrega un nuevo socio que retira un libro, etc.
costo de la serialización
Costo del aislamiento si lo llevo a serialización, necesidad de manejarlo a mano.
Pensar en el sistema de carga on-line de declaraciones de Ganancias de la AFIP el día que se vence. Ahí es muy difícil que tengas problemas de concurrencia, porque mi declaración no se pisa con la tuya. Entonces la serialización no trae ventajas y sí hace impracticable a un sistema con una BD relacional atrás.
Anomalías de concurrencia en el manejo con BDs
... to be continued ... falta un montonazo por poner
