Un comportement transactionnel est-il nécessaire en dehors des bases de données?

Question

Je n'oserais rien faire de complexe dans une base de données sans transaction. Il y a presque toujours une commande simple à utiliser. Mais lorsque vous commencez à utiliser d'autres données persistantes, vous ne bénéficiez pas de cette prise en charge de transaction aussi simple à utiliser. Quelques exemples sont

• systèmes de fichiers
• services Web (aucun de ceux que j'ai utilisés)

Même dans les données non persistantes, il est souvent utile d'annuler un bloc de travail à la suite d'une exception. Aucune des structures de données standard que vous obtenez avec une langue ne prend en charge les transactions.

Ce que j'aimerais savoir, c'est pourquoi les bases de données constituent un cas particulier?

Existe-t-il des liens utiles vers le sujet du comportement transactionnel en dehors des bases de données?

Answer 1

Je ne peux que désapprouver respectueusement: les systèmes transactionnels ne sont pas automatiquement et exclusivement des moteurs de base de données, bien au contraire ...

J'ai implémenté un mécanisme de transaction d'application (dans .NET) distinct d'une transaction de base de données. C'est en fait assez facile (quelques heures de travail, y compris une suite de tests unitaires). Il est entièrement écrit en C #, sans aucune dépendance des fonctionnalités de la base de données ou de tout autre composant. Mais d’abord un peu de contexte ...

Cette fonctionnalité sans transaction de base de données existe sous plusieurs manifestations sur la plate-forme Java, notamment avec les EJB, les ESB, JMS et souvent en association avec le MPM. Certaines de ces manifestations utilisent une base de données sous-jacente, mais pas toujours et par nécessité. D'autres plates-formes ont des manifestations comparables, telles que MSMQ.

La plupart des systèmes de contrôle de version hérités n'implémentent PAS la sémantique des transactions ACID. Comme Ddaa l'a dit, CVS ne le fait pas, mais Subversion (son successeur). Visual Source Safe ne le fait pas. Si vous effectuez des recherches sur Subversion, vous pouvez trouver des tableaux de comparaison qui en font ressortir le sens.

Désormais, pour le point critique, une transaction de base de données ou son équivalent ne garantit pas une logique métier sûre. Bien que j'aime Subversion, c'est ironiquement un excellent exemple de ce fait.

Vous pouvez utiliser Subversion de manière religieuse, avec un script de construction automatisé (une commande compilant, testant et conditionnant votre application), tout en validant une construction cassée dans le référentiel de contrôle de code source. Je l'ai vu à plusieurs reprises. Bien entendu, cela est encore plus facile avec des outils de contrôle de sources non basés sur ACID tels que VSS. Mais il est choquant pour beaucoup de gens d’apprendre que c’est possible avec des outils comme Subversion.

Permettez-moi de présenter le scénario, s'il vous plaît. Vous et un collègue développez une application et utilisez Subversion pour le référentiel de contrôle de source. Vous codez tous les deux et vous vous engagez occasionnellement dans le référentiel. Vous apportez quelques modifications, exécutez une nouvelle génération (recompilez tous les fichiers source) et tous les tests réussissent. Alors, vous validez vos modifications et rentrez chez vous. Votre collègue a travaillé sur ses propres modifications. Il exécute donc également une nouvelle génération, voit tous les tests réussis et s’engage dans le référentiel. Mais, votre collègue se met alors à jour à partir du référentiel, apporte quelques modifications supplémentaires, exécute une construction propre et la construction explose à la figure! Il annule à nouveau ses modifications, met à jour à partir du référentiel (juste pour en être sûr) et constate qu'une nouvelle version explose encore! Votre collègue passe les deux heures qui suivent à résoudre la création et la source, et trouve éventuellement une modification que vous avez effectuée avant votre départ et qui est à l'origine de l'échec de la génération. Il envoie un mauvais courriel à vous et à votre chef commun, se plaignant de ce que vous avez brisé le bâtiment et que vous êtes ensuite rentré chez vous. Vous arrivez dans la matinée pour trouver votre collègue et votre patron qui vous attendent à votre bureau et qui vous surveillent! Donc, vous exécutez rapidement une version propre et leur montrez que la version n'est pas cassée (tous les tests réussissent, comme hier soir).

Alors, comment est-ce possible? Cela est possible car le poste de travail de chaque développeur ne fait pas partie de la transaction ACID; Subversion ne garantit que le contenu du référentiel. Lorsque votre collègue s'est mis à jour à partir du référentiel, son poste de travail contenait une copie mixte du contenu du référentiel (y compris vos modifications) et ses propres modifications non validées. Lorsque votre collègue a exécuté une version propre sur son poste de travail, il invoquait une transaction commerciale qui n'était PAS protégée par la sémantique ACID. Lorsqu'il a annulé ses modifications et effectué une mise à jour, son poste de travail correspondait au référentiel, mais la construction était toujours défaillante. Pourquoi? Parce que votre poste de travail faisait également partie d'une transaction commerciale distincte qui n'était PAS non plus protégée par la sémantique ACID, contrairement à votre validation dans le référentiel. Comme vous n'aviez pas mis à jour votre poste de travail pour qu'il corresponde au référentiel avant de vous exécuter

Answer 2

Je pense que la raison pour laquelle les transactions ne sont visibles que dans les bases de données est que, par définition, les systèmes fournissant des transactions sont appelés des bases de données. Cela semble circulaire, donc je dois élaborer.

La prise en charge des transactions est la fonctionnalité qui fournit les propriétés de ACID . En termes simples, cela signifie qu'une transaction est quelque chose qui permet 1. de regrouper un certain nombre d'opérations discrètes dans un même package qui réussit dans son ensemble ou échoue dans son ensemble 2. masque les modifications non validées aux utilisateurs simultanés, de sorte que 3. les utilisateurs simultanés avoir à tout moment un " cohérent " vue du système.

Les

systèmes de fichiers offrent traditionnellement un mécanisme de verrouillage, mais c'est différent de fournir des transactions. Cependant, tous les systèmes de fichiers ont des propriétés atomiques. Par exemple, si vous avez les répertoires / a / et / b / et que vous essayez simultanément d'exécuter mv / a / b / a et mv / b / a / b , une seule de ces opérations réussira, sans compromettre l'intégrité. Ce qui manque généralement aux systèmes de fichiers, c’est cependant la possibilité de regrouper plusieurs opérations dans un seul groupe atomique isolé.

Une réponse mentionnée Subversion. Tous les systèmes de contrôle de version sane ont des transactions. Lorsqu’il s’engage sur plusieurs fichiers, le système applique le commit complètement ou le rejette complètement (sauf CVS, que je ne considère pas comme sain d’esprit). La cause du rejet est toujours un changement simultané. Les développeurs de systèmes de contrôle de version sont très conscients de la maintenance d'une base de données.

Une autre réponse a mentionné les systèmes de messagerie comme étant transactionnels . Je n'ai pas lu le matériel lié, mais la réponse elle-même ne mentionnait que la livraison atomique de messages. Ce ne sont pas des transactions.

Je n'ai jamais entendu parler de Clojure avant Brian C. l'a mentionné ici. Il me semble qu’il s’agit bien d’une implémentation de transactions en dehors du contexte d’une base de données. Ici, l’accent est mis sur le contrôle de la concurrence, plutôt que sur le maintien de la cohérence des données durables.

Ainsi, à l'exception de Clojure, il semble que tout système nécessitant des transactions utilise une base de données sous-jacente ou se transforme en base de données.

Answer 3

Les systèmes de fichiers modernes comportent des transactions. Ils sont simplement transparents pour l'utilisateur final.

NTFS, XFS, JFS, EXT3 et ReiserFS le sont tous, pour n'en nommer que quelques-uns.

Et cela ne concerne que le système de fichiers. De nombreux systèmes d'exploitation prennent également en charge le verrouillage de fichiers (voir flock (2) dans le monde * NIX, par exemple) avec des verrous exclusifs (écriture) et partagés (lecture).

Modifier: Si vous y réfléchissez, les systèmes de fichiers n'ont pas de niveaux d'isolation, contrairement aux bases de données modernes, car une fois que vous avez fini de lire un fichier, vous le fermez normalement si vous ne le verrouillez pas. Ensuite, vous le rouvrez quand vous voulez écrire.

Answer 4

Clojure utilise Mémoire transactionnelle logicielle , qui utilise des transactions pour faciliter l’écriture de programmes multithreads sans verrouillage manuel. Clojure a des structures de données immuables avec des références mutables, et des transactions sont nécessaires pour changer les références.

Answer 5

Les systèmes de messagerie sont un autre exemple de gestionnaire de ressources transactionnel.

En d'autres termes, vous pouvez vous assurer qu'un consommateur de message traite correctement un message de la file d'attente. Si le traitement échoue, le message reste dans la file d'attente.

En outre, un système de messagerie peut participer à une transaction distribuée avec un autre gestionnaire de ressources.

Plus d'infos sur

• https://java.sun.com/j2ee /1.4/docs/tutorial/doc/JMS6.html
• http://www.odi.ch/prog/jms-tx.php

Answer 6

Les validations Subversion sont transactionnelles: elles sont vraiment atomiques. Ainsi, une validation interrompue ne laisse pas le référentiel dans un état incohérent.

Answer 7

J'ai eu la situation nécessaire pour traiter un système de fichiers et une base de données comme une unité transactionnelle.

Dans mon cas, je n'avais besoin que de télécharger un ensemble de fichiers dans le système de fichiers. Je l'ai fait en créant chaque fois des répertoires aléatoires, en y mettant les données et en stockant le nom du répertoire dans une table de base de données. Par conséquent, tout le travail de ma base de données et le nom du répertoire dans la table de la base de données (= travail du système de fichiers) pourraient être effectués dans une transaction de base de données.

http://www.databasesandlife.com/atomic-operations -over-filesystem-and-database /