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.