Progress-4gl : Comment la portée de la transaction s'applique-t-elle à l'appel de programme externe ?
J'ai besoin d'aide pour comprendre la portée des transactions pour les procédures/programmes en dehors du programme actuel.
Supposons que j'ai trois programmes, le programme A, le programme B et le programme C. Dans le programme A, j'ai une procédure qui contient quelques lignes enveloppées dans un do transaction
bloc (pas fortement typé). Dans ce do transaction
bloc, il appelle un autre programme B. Au retour du programme B, il y a une commande d'annulation, de congé. Dans le même bloc de transaction, il appelle le programme C et a une annulation, quittez également après cet appel.
Ma question est la suivante: si dans le bloc de transaction, le programme B s'exécute sans erreur, mais que le programme c renvoie une erreur, l'annulation, le congé après l'appel du programme C annulera-t-il également les transactions qui se sont produites dans le programme B?
Procedure do_something:
some processing....
do transaction:
error-message = "".
{run programB.p}
if error-message <> "" then undo, leave.
some further processing...
error-message = "".
{run programC.p}
if error-message <> "" then undo, leave.
end. /* end of do transaction */
end procedure.
Réponses
Oui. Tout ce qui se passe dans le bloc de transaction sera annulé.
Oui. Dans l'exemple que vous décrivez, tout est annulé.
Ce n'est pas tant qu'elle est "étendue" en soi, mais simplement que la transaction inclut tout ce qui se passe dans cette session à partir du moment où elle est activée jusqu'à ce qu'elle soit validée ou annulée. Procédures internes, procédures externes, fonctions définies par l'utilisateur, méthodes de classes, code déclencheur, etc.
"Dans cette session" est important - si vous appelez une procédure sur un serveur d'applications, cette activité n'est PAS incluse car il s'agit de son propre processus avec son propre contexte de transaction distinct.
Lorsque des serveurs d'applications sont impliqués, les choses deviennent désordonnées. L'appelant d'origine n'a aucune capacité (intégrée) pour savoir quoi restaurer dans la session de serveur d'application appelée. L'appel du serveur d'application peut renvoyer une erreur entraînant l'annulation de l'appelant s'il rencontre des problèmes, mais l'appelant peut également décider d'intercepter et d'ignorer cette erreur.