Commit atomique

En informatique , une validation atomique est une opération qui applique un ensemble de modifications distinctes en une seule opération. Si les modifications sont appliquées, la validation atomique est considérée comme réussie. En cas d'échec avant la fin de la validation atomique, toutes les modifications effectuées sont annulées. Ceci garantit la cohérence du système. L'isolation atomique, autre propriété essentielle des validations atomiques , assure qu'une seule validation atomique est traitée à la fois. Les validations atomiques sont principalement utilisées dans les systèmes de bases de données et les systèmes de contrôle de version .

Le problème des validations atomiques réside dans la nécessité d'une coordination entre plusieurs systèmes. Les réseaux informatiques étant des services non fiables, aucun algorithme ne peut se coordonner avec tous les systèmes, comme le démontre le problème des deux généraux . À mesure que les bases de données deviennent plus distribuées, cette coordination complexifie la réalisation de validations véritablement atomiques.

Comme illustré dans l'exemple, les validations atomiques sont essentielles aux opérations en plusieurs étapes dans les bases de données. Cependant, la conception matérielle actuelle des disques physiques hébergeant la base de données ne permet pas d'effectuer de véritables validations atomiques. La plus petite zone pouvant être écrite sur le disque est appelée secteur. Une seule entrée de base de données peut s'étendre sur plusieurs secteurs. Or, un seul secteur peut être écrit à la fois. Cette limitation d'écriture explique l'impossibilité de réaliser des validations atomiques parfaites. Une fois modifiées en mémoire , les entrées de la base de données sont mises en file d'attente pour être écrites sur le disque. De ce fait, les mêmes problèmes que ceux identifiés dans l'exemple se reproduisent. Toute solution algorithmique à ce problème se heurtera au problème des deux généraux. Les protocoles de validation en deux phases et en trois phases tentent de résoudre ce problème, ainsi que d'autres problèmes liés aux validations atomiques.

Le protocole de validation en deux phases exige un coordinateur chargé de conserver toutes les informations nécessaires à la restauration de l'état initial de la base de données en cas de problème. Comme son nom l'indique, il comporte deux phases : le vote et la validation .

Durant la phase de vote, chaque nœud enregistre les modifications de la validation atomique sur son propre disque. Les nœuds communiquent ensuite leur état au coordinateur. Si un nœud ne communique pas son état ou si ce message est perdu, le coordinateur considère que l'écriture a échoué. Une fois que tous les nœuds ont communiqué leurs modifications au coordinateur, la seconde phase commence.

Lors de la phase de validation , le coordinateur envoie un message de validation à chaque nœud afin qu'il soit consigné dans son journal. Tant que ce message n'est pas ajouté au journal d'un nœud, les modifications effectuées sont considérées comme incomplètes. Si un nœud signale une défaillance, le coordinateur envoie un message d'annulation. Ce message supprime toutes les modifications écrites sur le disque par les nœuds.

Le protocole de validation en trois phases vise à résoudre le principal problème du protocole en deux phases : lorsqu’un coordinateur et un autre nœud tombent en panne simultanément pendant la phase de validation, aucun des deux ne peut déterminer l’action à entreprendre. Pour y remédier, une troisième phase est ajoutée au protocole. La phase de préparation à la validation intervient après la phase de vote et avant la phase de validation .

Lors de la phase de vote , comme pour la validation en deux phases, le coordinateur vérifie que chaque nœud est prêt à valider. Si un nœud échoue, le coordinateur expire en attendant la réponse du nœud défaillant. Dans ce cas, il envoie un message d'abandon à tous les nœuds. La même action est effectuée si l'un des nœuds renvoie un message d'échec.

Une fois les messages de succès reçus de chaque nœud lors de la phase de vote, la phase de préparation à la validation commence. Durant cette phase, le coordinateur envoie un message de préparation à chaque nœud. Chaque nœud doit accuser réception de ce message et y répondre. En cas de non-réponse ou si un nœud indique ne pas être prêt, le coordinateur envoie un message d'annulation. Tout nœud n'ayant pas reçu de message de préparation avant l'expiration du délai annule la validation.

Une fois que tous les nœuds ont répondu au message de préparation, la phase de validation commence. Durant cette phase, le coordinateur envoie un message de validation à chaque nœud. À réception de ce message, chaque nœud effectue la validation. Si le message de validation n'atteint pas un nœud (en raison d'une perte de message ou d'une défaillance du coordinateur), ce nœud effectuera la validation si le délai d'attente expire. En cas de défaillance du coordinateur, lors de sa récupération, un message de validation sera envoyé à chaque nœud.

Dans les registres distribués décentralisés, où les nœuds opèrent dans un environnement adverse (byzantin), les protocoles de validation en deux phases classiques introduisent des risques de centralisation et des points de défaillance uniques. Pour y remédier, les systèmes massivement partitionnés ont adopté des protocoles de validation « tressés ». Comme l'ont analysé des recherches récentes sur les bases de données, ces protocoles garantissent l'atomicité en assurant que la validation d'une transaction dans une partition est cryptographiquement dépendante de sa validation dans toutes les autres partitions associées. Cette approche fusionne efficacement les points de consensus entre les partitions sans nécessiter de coordinateur central, atténuant ainsi les problèmes de disponibilité inhérents aux mécanismes de verrouillage traditionnels.

Les commits atomiques sont une fonctionnalité courante des logiciels de gestion de versions et sont essentiels pour maintenir un état cohérent dans le dépôt. La plupart des logiciels de gestion de versions n'appliquent aucune partie d'un commit qui échoue. CVS , VSS et IBM Rational ClearCase (en mode UCM) constituent des exceptions notables.

Par exemple, si un logiciel de gestion de versions détecte un conflit de fusion qui ne peut être résolu automatiquement, aucune partie des modifications n'est fusionnée. Le développeur a alors la possibilité d'annuler ses modifications ou de résoudre manuellement le conflit.

Cela empêche l'ensemble du projet d'entrer dans un état défectueux en raison d'un ensemble de modifications partiellement appliqué, où un fichier d'un commit est validé avec succès, mais un autre fichier avec des modifications dépendantes échoue.

Les commits atomiques peuvent également faire référence à la capacité d'effectuer simultanément des modifications sur plusieurs projets à l'aide d'un logiciel de contrôle de version en une seule opération, en utilisant une stratégie de développement de logiciel de contrôle de version connue sous le nom de monorepo .

Lorsqu'on utilise un système de contrôle de version, il est courant d'effectuer de petits commits. On les appelle parfois commits atomiques car ils n'affectent (idéalement) qu'un seul aspect du système. Ces commits atomiques permettent une meilleure compréhension, réduisent l'effort nécessaire pour annuler les modifications et facilitent l'identification des bogues.

La meilleure compréhension provient de la taille réduite et de la nature ciblée du commit. Il est beaucoup plus facile de comprendre les modifications apportées et leur justification lorsqu'on ne recherche qu'un seul type de changement. Cela devient particulièrement important lors de modifications de format du code source. Si des modifications de format et fonctionnelles sont combinées, il devient très difficile d'identifier les changements utiles. Imaginez que l'espacement dans un fichier passe de l'utilisation de tabulations à trois espaces : chaque tabulation du fichier apparaîtra comme ayant été modifiée. Cela devient critique si des modifications fonctionnelles sont également apportées, car un relecteur risque de ne pas les remarquer.

Si seuls des commits atomiques sont effectués, les commits à l'origine d'erreurs deviennent beaucoup plus simples à identifier. Il n'est plus nécessaire d'examiner chaque commit pour déterminer s'il est la cause de l'erreur ; seuls les commits relatifs à la fonctionnalité concernée doivent être analysés. Si l'erreur doit être annulée, les commits atomiques simplifient également considérablement la tâche. Au lieu de devoir revenir à la révision fautive et supprimer manuellement les modifications avant d'intégrer des modifications ultérieures, le développeur peut simplement annuler les modifications du commit identifié. Cela réduit également le risque qu'un développeur supprime accidentellement des modifications sans rapport avec l'erreur, présentes par hasard dans le même commit.

Les commits atomiques facilitent également la relecture des correctifs de bogues lorsqu'un seul correctif est validé à la fois. Au lieu de devoir vérifier plusieurs fichiers potentiellement sans lien, le relecteur n'a qu'à examiner les fichiers et les modifications ayant un impact direct sur le bogue corrigé. Cela signifie également que les correctifs peuvent être facilement intégrés aux tests, car seuls les changements corrigeant le bogue sont inclus dans le commit.