50 ans plus tard, le two-phase locking est-il ce que nous pouvons faire de mieux ?

• Cet article traite du concept de Two-Phase Locking (2PL), un mécanisme général de contrôle de concurrence inventé il y a environ 50 ans.
• Le 2PL offre des niveaux d’isolation plus forts, à savoir la sérialisabilité et l’opacité, et il est utilisé pour les transactions portant sur plusieurs éléments de données.
• L’auteur souligne que la simplicité du 2PL et ses solides niveaux d’isolation constituent ses principaux avantages.
• Cependant, le 2PL présente des inconvénients, notamment une mauvaise scalabilité en lecture et une progression sujette au live-lock.
• L’auteur présente un nouveau mécanisme de contrôle de concurrence, Two-Phase Locking Starvation-Free (2PLSF), qui vise à résoudre les problèmes du 2PL.
• Le 2PLSF utilise de meilleurs verrous lecteur-rédacteur et offre des transactions sans famine, qui correspondent à la forme la plus élevée de progression bloquante.
• Le 2PLSF est efficace pour résoudre certains types de conflits, ce qui lui permet de passer à l’échelle même lorsque certains conflits se produisent.
• L’auteur conclut que le 2PLSF représente une amélioration majeure par rapport au 2PL, en comparant la différence entre les deux à celle entre un marteau-piqueur et une pioche.
• L’article inclut des liens vers un article scientifique sur l’algorithme 2PLSF ainsi que vers son code source, pour aller plus loin.

[GN⁺]

Avis Hacker News

• Article discutant du two-phase locking (2PL) et de sa pertinence 50 ans après son développement initial.
• Un commentateur indique être débutant sur le sujet et cherche une solution de cohérence facile à déployer pour une architecture distribuée en microservices.
• Le même commentateur partage du code Python pour tester le non-déterminisme dans un environnement de multiprocessus multithread.
• Un autre commentateur suggère de d’abord se demander si un algorithme de verrouillage est réellement nécessaire, et propose de regrouper les requêtes par lots afin de réduire la concurrence et le verrouillage.
• Une question est posée sur la comparaison entre cette nouvelle approche et la Serializable Snapshot Isolation (SSI), présentée comme une version améliorée du 2PL.
• Un commentateur propose qu’une nouvelle règle de Hacker News impose que tous les liens publiés soient en HTTPS.
• Un lien est partagé vers l’article de l’auteur sur 2PLSF, qu’il présente comme ce que le 2PL aurait dû être à l’origine.
• Il est proposé d’ajouter une file d’attente aléatoire pour améliorer la scalabilité des opérations atomiques.
• Une question est posée sur la nécessité de récupérer et d’ajouter des identifiants de transaction dans l’approche Wait-Or-Die, avec la suggestion d’utiliser à la place des identifiants de thread ou des nombres aléatoires.
• Un commentateur dit ne pas comprendre la dernière figure sur les arbres AVL relâchés dans le contexte des transactions en lecture seule.
• Une question est posée sur l’applicabilité du 2PL dans le contexte d’appels API faiblement couplés.
• Un commentateur souligne que la plupart des transactions d’écriture ont besoin de lectures cohérentes sur de nombreux objets fortement disputés, alors que les écritures réelles ne portent souvent que sur un ou deux objets, et demande si le 2PL répond à ce problème.