> Tech > Modèle d’application pour des transactions du genre « toutes ou aucune »

Modèle d’application pour des transactions du genre « toutes ou aucune »

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

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 »

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

Percer le brouillard des rançongiciels

Percer le brouillard des rançongiciels

Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010