50 anos depois, o two-phase locking é o melhor que conseguimos fazer?

• Este artigo discute o conceito de Two-Phase Locking (2PL), um mecanismo comum de controle de concorrência inventado há cerca de 50 anos.
• O 2PL fornece níveis de isolamento mais fortes, como Serializability e Opacity, e é usado em transações sobre vários itens de dados.
• O autor destaca como principais vantagens do 2PL sua simplicidade e seus fortes níveis de isolamento.
• No entanto, o 2PL tem desvantagens como baixa escalabilidade de leitura e progresso com live-lock.
• O autor apresenta o Two-Phase Locking Starvation-Free (2PLSF), um novo controle de concorrência que resolve os problemas do 2PL.
• O 2PLSF usa um bloqueio reader-writer melhor e oferece transações livres de starvation, a forma mais forte de progresso com bloqueio.
• O 2PLSF é eficaz para resolver certos tipos de conflito, o que permite escalar mesmo quando alguns conflitos ocorrem.
• O autor conclui que o 2PLSF é uma grande melhoria em relação ao 2PL, comparando a diferença entre eles à de uma britadeira e uma picareta.
• O artigo inclui links para o paper sobre o algoritmo 2PLSF e para o código-fonte, que podem ser consultados para estudo adicional.

[GN⁺]

Comentários do Hacker News

• Artigo sobre o two-phase locking (2PL) e sua relevância 50 anos após ter sido desenvolvido pela primeira vez.
• Um comentarista diz ser iniciante no assunto e estar procurando uma solução de consistência fácil de implantar para uma arquitetura distribuída de microsserviços.
• O mesmo comentarista compartilha código em Python para testar não determinismo em um ambiente de multiprocessamento multithread.
• Outro comentarista sugere considerar primeiro se um algoritmo de bloqueio é realmente necessário e propõe agrupar requisições em lote para reduzir concorrência e bloqueios.
• É levantada uma pergunta sobre como a nova abordagem se compara ao Serializable Snapshot Isolation (SSI), anunciado como uma versão melhorada do 2PL.
• Um comentarista sugere que o Hacker News deveria ter uma nova política exigindo que todos os links publicados usem HTTPS.
• É compartilhado um link para o artigo do autor sobre 2PLSF, que ele argumenta ser o que o 2PL deveria ter sido desde o início.
• É sugerido adicionar filas aleatórias para melhorar a escalabilidade de operações atômicas.
• Surge uma pergunta sobre se, na abordagem Wait-Or-Die, é necessário obter e adicionar IDs de transação, sugerindo usar IDs de thread ou números aleatórios no lugar.
• Um comentarista diz não entender a última figura sobre árvores AVL relaxadas no contexto de transações somente leitura.
• É levantada uma pergunta sobre a aplicabilidade do 2PL no contexto de chamadas de API fracamente acopladas.
• Aponta-se que a maioria das transações de escrita precisa de leituras consistentes sobre muitos objetos disputados, mas que as escritas reais geralmente envolvem apenas um ou dois objetos, questionando se o 2PL resolve isso.