Concevoir des applications pour fournir des transactions « toutes ou aucune » n’est pas beaucoup plus compliqué que d’incorporer une logique similaire à l’exemple précédent, dans votre structure applicative. Le point essentiel est qu’il faut concevoir la logique d’exécution de sorte qu’il y ait des points clairement identifiés qui définissent
Modèle d’application pour des transactions du genre « toutes ou aucune »
![Modèle d’application pour des transactions du genre « toutes ou aucune » Modèle d’application pour des transactions du genre « toutes ou aucune »](https://www.itpro.fr/wp-content/uploads/2016/06/be75dba2ff879a7c1027b53d41e5e92d.png)
les « limites » des transactions, c’est-à-dire, les points de début et de fin pour chaque type de transaction. Beaucoup d’applications ne demandent qu’un point de contrôle de transaction qui marque l’endroit où la transaction précédente se termine et où la suivante commence.
Un point de fin de transaction est le seul endroit pour coder une opération Commit pour ce genre d’opération, à l’aide d’une logique semblable à celle-ci :
If transaction-successful { Commit } else { Rollback }
Dans ce cas, il faut initialiser la variable d’état au point de début de transaction, de la manière suivante :
transaction-successful = TRUE
Ensuite, dans le code qui exécute les étapes de la transaction (par exemple, calculs et mises à jour de la base de données), on peut utiliser une variante de la logique montrée plus haut :
Update savings table
If error { transaction-successful = FALSE }
else { Update checking table
If error { transaction-successful = FALSE } }
Bien entendu, on pourrait obtenir le même résultat par une variante de la logique de transaction. Il faut surtout éviter d’éparpiller les opérations Commit au fil du code. Tout flux d’exécution devrait aboutir à un point de « fin de transaction », et c’est précisément là que le Commit est à sa place. Veillez aussi à ce que l’exécution atteigne toujours une opération Rollback quand une erreur survient pendant le traitement de la transaction. Vous pouvez utiliser une variable d’état de transaction (comme montré ci-dessus), mettre des opérations Rollback au point de défaillance, ou combiner les deux. Il n’est pas gênant d’exécuter des Rollback superflus ou redondants, pour autant que l’environnement du contrôle de commitment reste actif.
Téléchargez cette ressource
![Microsoft 365 : 5 erreurs de sécurité](https://www.itpro.fr/wp-content/uploads/2022/07/Guide-de-Securite-Office-365-les-5-erreurs-a-ne-pas-commettre-Expertise-DIB-France.png)
Microsoft 365 : 5 erreurs de sécurité
A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Stimuler l’innovation durable grâce à la transformation numérique et aux principes ESG
- Retour au bureau avec Copilot M365
- Les entreprises optent pour des solutions durables
- Le rôle clé du no-code/low-code dans la transformation numérique
- Le rôle de l’intelligence Artificielle dans le Cloud Computing
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)