Discussion :

[couse1]

Bonjour,

je voudrais connaitre les meilleurs pratiques pour gérer le commit notamment au
niveau des procédures (fonctions...).
Est ce que l'on commit à l'intérieur ou à l'extérieur des procédures?
Si c'est à l'extérieur : le commit serait-il placé juste après l'appel de la procédure avec un rollback au niveau des exceptions du corps appelant?


Merci pour vos réponses
Cordialement
couse1

[Scriuiw]

Jamais dans une fonction, très peu conseillé dans une procédure anonyme, sinon en fin de procédure principale dans un package ou laisser le commit se faire lors de la fermeture de la connexion à la BDD

Gestion des rollback dans les blocs exception avec un RAISE pour transmettre l'erreur à l'appelant

[skuatamad]

Une discussion plutôt orientée sur le rollback mais dans laquelle tu trouveras plusieurs lien vers la doc et asktom qui parlent du sujet.
Prévoir un Rollback dans une procédure

[pachot]

Bonjour,

C'est normalement au niveau le plus haut que se gèrent les transactions et les exceptions. Parce que si tu commit dans une procédure, tu ne sait pas ce qu'a fait la session avant d'appeler la procédure, et tu risque de valider des modifications sans que l’appelant ne le sache. Et si la session appelante fait encore des modifications après l'appel à la procédure et rencontre une erreur, elle voudra peut-être faire un rollback de tout - et ne saura pas que la moitié a déjà été validé.

Pour la gestion des exceptions, c'est pareil: les exceptions qui sont vraiment des erreurs doivent remonter au niveau le plus haut pour avoir un message d'erreur qui permet de comprendre d'où vient l'erreur. Et c'est à ce niveau que le rollback sera fait.

Il y a des exceptions à cette règle:
- un gros chargement qui doit faire des commit intermédiaires, s'il est codé dans une procédure, aura un commit dans sa boucle. Dans ce cas, le programme appelant doit savoir qu'il y aura un commit implicite (un peu comme ce qu'il se passe lorsqu'on fait du DDL)
- une exception à laquelle on s'attend et qui est gérée dans le code peut être faire un rollback to savepoint pour annuler uniquement les modifications qu'on connaît.
- on peut avoir envie de faire persister une info même si la transaction fait un rollback plus tard (par exemple enregistrer un log d'erreur dans une table). Alors on va utiliser une autonomous transaction qui va faire cette écriture avec un commit sans toucher à la transaction principale.

Par niveau le plus haut, j'entend celui qui couvre l'interaction utilisateur. Le but c'est de pouvoir dire à l'utilisateur:
- soit 'ok: tout est validé'
- soit 'erreur: rien n'est fait'. Afin de ne pas laisser des modifications faites à moitié. L'utilisateur peut alors tout relancer lorsque c'est corrigé.
- ou parfois, si c'est prévu, on peut avoir des commit intermédiaires et retourner une erreur du genre 'erreur: seulement les 1000 premiers enregistrements sont validés.' Alors l'utilisateur peut reprendre où ça s'est arrêté.

Cordialement,
Franck.

[ctobini]

Bonjour,

Je déterre le post, je suis en train de m'intéresser aux COMMIT / ROLLBACK et EXCEPTION sous Oracle 11g.

Lorsque vous déconseillez d'effectuer les COMMIT / ROLLBACK et EXCEPTION dans les procédures, est-ce que schématiquement cela veut dire que la procédure doit être créee sans cette gestion :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
create or replace 
procedure maProc(inp in varchar2) is
begin
 insert into maTab(col1) values(inp);
end;
 
-- simple insertion dans une colonne de table
-- avec maTab(col1 char(5))

Puis appelée, dans mon exemple dans un bloc anonyme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
begin
 maProc('hhhhhhhh'); -- trop de caractères
 commit;
 exception when others then dbms_output.put_line('Problème de taille !');
end;

Dans l'exemple ci-dessus, une chaîne de caractère trop longue est saisie, c'est suite à l'exécution de la procédure stockée que l'erreur et le COMMIT sont gérés.