solucionario-transacciones-icop

Bases de Datos II - Taller de Transacciones PostgreSQL

Profesora: María Eugenia Weibel
Material: Respuestas Completas y Explicaciones Detalladas

PARTE 1: Exploración Inicial

1. ¿Qué elementos principales observas en la interfaz?

Respuesta Esperada: - Panel Transacción A (izquierda) con vista de BD, SQL y estado - Panel Transacción B (derecha) con vista de BD, SQL y estado
- Log de eventos del sistema (centro inferior) - Controles superiores (botones demo y selector aislamiento) - Panel explicación (inferior)

Criterio de Evaluación: Identifica al menos 3 elementos principales

2. ¿Cuántas transacciones simultáneas puedes simular?

Respuesta: 2 transacciones (A y B)

3. ¿Cuál es el nivel de aislamiento por defecto?

Respuesta: READ COMMITTED

Nota Pedagógica: Este es el nivel por defecto de PostgreSQL

4. ¿Qué datos iniciales tiene la tabla?

Respuesta: - ID: 1, Saldo: $1000, Usuario: Juan - ID: 2, Saldo: $500, Usuario: María
- ID: 3, Saldo: $750, Usuario: Pedro

PARTE 2: Demo Básica

5. ¿Qué sucede en el primer paso de la Transacción A?

SQL Ejecutada:

BEGIN;
SELECT * FROM accounts WHERE id = 1;

Cambio Visual: Registro ID=1 se resalta (modificado)

Explicación: A inicia y lee el registro. En MVCC, las lecturas no bloquean.

6. ¿Comportamiento de Transacción B al modificar mismo registro?

Estado: Amarillo (waiting) Significado: B espera porque A ya modificó el registro

Concepto Clave: Row-level locking previene lost updates

7. ¿Cuándo debe esperar la Transacción A?

Momento: Cuando intenta UPDATE del registro que B tiene bloqueado Razón: Conflicto de escritura - ambas compiten por mismo recurso Log: “Transacción A: Intentando actualizar el mismo registro” (warning)

8. ¿Orden final de ejecución?

Secuencia: 1. A: BEGIN + SELECT (lee $1000) 2. B: BEGIN + UPDATE (lock en ID=1, cambia a $1200) 3. A: Intenta UPDATE (bloqueada) 4. B: COMMIT (libera lock) 5. A: UPDATE procede (cambia a $800) 6. A: COMMIT

¿Por qué este orden? PostgreSQL usa “first-come, first-served” para locks

9. ¿Saldo final sin control de transacciones?

Sin locks: Race condition - resultado impredecible - Si ambas leen $1000 inicialmente - Una actualización se perdería (lost update) Con locks: $800 (determinístico y correcto)

10. ¿Qué mecanismo previene lost update?

Mecanismo: Row-level locking Funcionamiento: Lock exclusivo impide modificaciones concurrentes

PARTE 3: Niveles de Aislamiento

READ UNCOMMITTED:

11. ¿Cambia algo vs READ COMMITTED?

Respuesta: NO en esta demo específica Razón: Demo usa principalmente escrituras, los write-locks son iguales

12. ¿Qué riesgos adicionales?

Problema 1: Dirty reads - leer datos no confirmados Problema 2: Decisiones basadas en datos que pueden revertirse

REPEATABLE READ:

13. ¿Comportamiento diferente a READ COMMITTED?

Respuesta: NO en esta demo Razón: Se enfoca en write conflicts, manejados igual en ambos niveles

14. ¿Cuándo notarías la diferencia?

Escenario: Reportes que requieren múltiples consultas consistentes sobre mismos datos

SERIALIZABLE:

15. ¿Diferencias en demo básica?

Respuesta: NO directamente observables Overhead: Mayor detección de conflictos, posibles rollbacks adicionales

16. ¿Cuándo usar SERIALIZABLE?

Ejemplo 1: Sistemas financieros críticos Ejemplo 2: Auditorías que requieren consistencia absoluta

PARTE 4: Simulación de Deadlock

17. ¿Qué registros bloquea cada transacción?

Transacción A: ID=1 ($1000 → $900) Transacción B: ID=2 ($500 → $600)

18. ¿Cuándo se produce deadlock?

Secuencia: - A lock ID=1, intenta ID=2 - B lock ID=2, intenta ID=1 - Dependencia circular = ¡deadlock!

19. ¿Cómo se visualiza?

Indicadores: Ambos rojos (error) Log: “¡DEADLOCK DETECTADO! PostgreSQL elige víctima”

20. ¿Cuál transacción es víctima?

Elegida: Transacción A Criterio: PostgreSQL elige la “menos costosa” de abortar

21. ¿Qué pasa con cambios de víctima?

¿Se pierden? SÍ - ROLLBACK automático ¿Por qué? Necesario para romper deadlock y mantener consistencia

22. ¿Cómo prevenir este deadlock?

Estrategia 1: Orden consistente - siempre ID menor primero Estrategia 2: Timeouts más cortos, transacciones más breves

23. ¿Tiempo de detección?

Observado: ~1 segundo ¿Configurable? SÍ - parámetro deadlock_timeout

PARTE 5: Problemas de Concurrencia

Dirty Read:

24. ¿Qué lee Transacción B inicialmente?

Valor: $1500 (modificado pero no confirmado) ¿Confirmado? NO

25. ¿Problema en sistema real?

Ejemplo: Transferencia bancaria - mostrar dinero “fantasma” que podría revertirse, llevando a decisiones erróneas

Dirty Read Prevenido:

26. ¿Diferencia en comportamiento?

Bloqueo: B se bloquea hasta que A confirme cambios

27. ¿Cuándo puede continuar B?

Condición: Cuando A haga COMMIT o ROLLBACK

28. ¿Qué lee finalmente B?

Valor: $1500 (confirmado) ¿Por qué correcto? Es el valor real y permanente

Phantom Read:

29. ¿Cuántos registros cuenta?

Primera: 3 registros Segunda: 4 registros (aparece Ana con $600)

30. ¿Por qué aparece fantasma?

Explicación: REPEATABLE READ garantiza que registros existentes no cambien, pero permite nuevas inserciones que cumplan criterios

31. ¿Cómo previene SERIALIZABLE?

Diferencia: B se bloquea al insertar, o detecta conflicto serialización

32. ¿Costo de prevención?

Rendimiento: Mayor CPU/memoria para tracking, más rollbacks, menor concurrencia

PARTE 6: Non-Repeatable Read

33. ¿Valores leídos por A?

Primera: $1000 Segunda: $1300

34. ¿Por qué cambia?

Causa: B modificó y confirmó cambio entre las dos lecturas de A

35. ¿Escenarios problemáticos?

Ejemplo: Cálculo de intereses que lee saldo inicial y final - si cambia entre medio, cálculo incorrecto

36. ¿Cómo solucionar?

Solución: REPEATABLE READ o SERIALIZABLE

PARTE 7: Información Detallada

37. ¿Cuatro niveles de aislamiento?

READ UNCOMMITTED - Permite todos los problemas
READ COMMITTED - Previene dirty reads
REPEATABLE READ - Previene dirty + non-repeatable reads
SERIALIZABLE - Previene todos los problemas

38. ¿Tipos de locks?

Row-level (FOR UPDATE, FOR SHARE, etc.)
Table-level (varios modos ACCESS SHARE a ACCESS EXCLUSIVE)
Advisory (controlados por aplicación)
Page-level (automáticos)

39. ¿Qué significa FOR UPDATE?

Significado: Lock exclusivo en filas seleccionadas Uso: Cuando planeas modificar datos leídos (read-then-write)

40. ¿Qué son Advisory Locks?

Definición: Locks controlados por aplicación, no automáticos Diferencia: Deben solicitarse y liberarse explícitamente

PARTE 8: Síntesis y Casos Prácticos

41. Nivel apropiado para:

Sistema bancario: SERIALIZABLE - consistencia crítica Sistema reportes: REPEATABLE READ - consistencia interna Blog personal: READ COMMITTED - balance rendimiento/consistencia

42. ¿Cuándo preferir deadlock vs dirty read?

Justificación: Sistemas críticos (financiero/médico) donde datos incorrectos son peores que retrasos. Deadlock preserva integridad.

43. ¿Balance consistencia/rendimiento?

Decisión: Analizar criticidad datos, frecuencia conflictos, tolerancia inconsistencias. Empezar READ COMMITTED, subir si necesario.

44. Escenario E-commerce:

Problema: Race condition en verificación stock Solución: SELECT FOR UPDATE o reservas temporales con timeout

45. Sistema reservas:

Configuración: REPEATABLE READ + SELECT FOR UPDATE Mecanismos: Locks en recursos limitados, timeouts para liberar

46. Sistema análisis:

Separación: Réplicas lectura para reportes, escrituras cortas primario Niveles: READ COMMITTED escrituras, REPEATABLE READ análisis

PARTE 9: Evaluación Final

47. Propiedades ACID:

Atomicidad: WAL + rollback automático Consistencia: Constraints + triggers + validaciones Isolación: MVCC + sistema locks Durabilidad: Sync disco + WAL persistente + checkpoints

48. Ventajas MVCC:

Readers no bloquean writers
Writers no bloquean readers
Snapshots consistentes sin locks complejos
Rollback eficiente

49. ¿Cuándo FOR UPDATE?

Caso 1: Operaciones read-then-write Caso 2: Lógica negocio que requiere exclusión mutua Caso 3: Sistemas queue/cola con múltiples workers

50. Consideraciones sistema crítico:

Punto 1: Nivel aislamiento apropiado para cada operación Punto 2: Transacciones cortas para minimizar contención Punto 3: Retry logic para deadlocks/errores serialización Punto 4: Monitoreo continuo locks/deadlocks/transacciones largas Punto 5: Separar OLTP de OLAP

PARTE 10: Reflexión

51-55. Preguntas de Autoevaluación:

Evaluación: Buscar evidencia de: - Identificación conceptos desafiantes específicos - Conexión entre demos y aprendizaje - Planes concretos aplicación práctica - Curiosidad por temas relacionados - Feedback constructivo sobre herramienta

Desafío Extra

56. Algoritmo detección deadlocks:

Respuesta esperada: Wait-for graph, detección ciclos cada deadlock_timeout, elección víctima por costo rollback

57. Caso uso complejo:

Evaluación: Diseño que demuestre uso apropiado diferentes niveles según operación

58. Mejoras simulador:

Sugerencias típicas: Más transacciones, diferentes operaciones, métricas rendimiento

Criterios de Evaluación

Precisión Técnica (40%):

90-100%: Respuestas técnicas correctas, terminología apropiada
80-89%: Mayoría correctas, errores menores terminología
70-79%: Conceptos básicos correctos, detalles incorrectos
60-69%: Errores significativos conceptos fundamentales
<60%: Falta comprensión básica

Comprensión Conceptual (30%):

90-100%: Entendimiento profundo ACID, MVCC, trade-offs
80-89%: Buen entendimiento general, explica mayoría conceptos
70-79%: Comprensión básica superficial
60-69%: Confusión conceptos clave
<60%: No demuestra comprensión fundamental

Aplicación Práctica (20%):

90-100%: Excelente conexión teoría-práctica, casos realistas
80-89%: Buena aplicación escenarios reales
70-79%: Aplicación básica apropiada
60-69%: Dificultad conectar aplicaciones reales
<60%: No puede aplicar conceptos prácticamente

Análisis Crítico (10%):

90-100%: Reflexión profunda, identifica trade-offs
80-89%: Buen análisis situaciones presentadas
70-79%: Análisis básico apropiado
60-69%: Análisis superficial
<60%: No demuestra capacidad análisis

Errores Comunes

1. Confusiones Típicas:

Dirty Read vs Non-Repeatable: Distinguir no confirmado vs confirmado-modificado
MVCC vs Locking: MVCC reduce locks lectura, no los elimina
Deadlock vs Lock Wait: Deadlock requiere dependencia circular

2. Señales de Alerta:

Respuestas muy vagas sin especificidad
Uso terminología sin comprensión real
No reconocer problemas concurrencia escenarios reales

INSTITUTO SUPERIOR ICOP
Excelencia Académica en Tecnología