50 años después, ¿el two-phase locking es lo mejor que podemos hacer?

• Este artículo analiza el concepto de Two-Phase Locking (2PL), un método general de control de concurrencia inventado hace unos 50 años.
• 2PL ofrece niveles de aislamiento más fuertes, como Serializability y Opacity, y se utiliza para transacciones sobre múltiples elementos de datos.
• El autor destaca como principales ventajas de 2PL su simplicidad y sus fuertes niveles de aislamiento.
• Sin embargo, 2PL tiene desventajas como una baja escalabilidad de lectura y progreso con live-lock.
• El autor presenta Two-Phase Locking Starvation-Free (2PLSF), un nuevo control de concurrencia que resuelve los problemas de 2PL.
• 2PLSF utiliza un mejor bloqueo reader-writer y ofrece transacciones libres de inanición, la forma más alta de progreso con bloqueo.
• 2PLSF es eficaz para resolver ciertos tipos de conflictos, por lo que puede escalar incluso cuando ocurren algunos conflictos.
• El autor concluye que 2PLSF es una mejora importante frente a 2PL, y lo compara con la diferencia entre un martillo neumático y un pico.
• El artículo incluye enlaces a un paper sobre el algoritmo 2PLSF y a su código fuente para profundizar en el tema.

[GN⁺]

Opiniones de Hacker News

• Un artículo sobre el debate en torno al bloqueo en dos fases (2PL) y su relevancia 50 años después de que se desarrolló por primera vez.
• Un comentarista menciona que es principiante en el tema y está buscando una solución de consistencia fácil de desplegar para una arquitectura distribuida de microservicios.
• El mismo comentarista comparte código en Python para probar la no determinación en un entorno multiproceso y multihilo.
• Otro comentarista sugiere considerar primero si realmente se necesita un algoritmo de bloqueo, y propone procesar solicitudes por lotes para reducir la concurrencia y los bloqueos.
• Se plantea una pregunta sobre cómo se compara este nuevo enfoque con Serializable Snapshot Isolation (SSI), anunciado como una versión mejorada de 2PL.
• Un comentarista propone que Hacker News necesite una nueva política según la cual todos los enlaces publicados deban usar HTTPS.
• Se comparte un enlace al artículo del autor sobre 2PLSF, que sostiene que eso es lo que 2PL debió haber sido originalmente.
• Se propone agregar colas aleatorias para mejorar la escalabilidad de las operaciones atómicas.
• Se plantea una pregunta sobre si es necesario obtener y agregar IDs de transacción en el enfoque Wait-Or-Die, y se sugiere usar en su lugar IDs de hilo o números aleatorios.
• Un comentarista dice que no entiende la última figura sobre árboles AVL relajados en el contexto de transacciones de solo lectura.
• Se plantea una pregunta sobre la aplicabilidad de 2PL en el contexto de llamadas a API débilmente acopladas.
• Se señala que la mayoría de las transacciones de escritura requieren lecturas consistentes sobre muchos objetos muy disputados, pero que las escrituras reales a menudo solo involucran uno o dos objetos, y se pregunta si 2PL resuelve esto.