Transaction et programmation [Résolu]

[loustalet]

Bonjour,

Je suis en train d'écrire une application en C# qui gère des inscriptions à des congrès.
Tous les ordres insert sont dans des procédures stockées incluses dans des packages.
Il y a des procédures publiques et privées dans ce package.
J'ai donc dans mon applicatif une classe qui contient une Oracleconnection, et une méthode chargée de créer une commande et valoriser les paramètres à partir des champs saisis. Cette méthode appelle ensuite une procédure d'un package Oracle. Cette procédure fait appel à d'autres procédures pour insérer dans différentes tables.
Ma question est de savoir si il vaut mieux commencer et terminer ma transaction dans le code la méthode de ma classe C# avec un objet OracleTransaction, ou bien commencer (implicitement) ma transaction et la terminer dans la procédure stockée appelée depuis mon code C#.

J'opterais pour la deuxième solution, mais je ne suis aps certain !
Merci pour vos lumières.

[mnitu]

La procédure appelée ne doit pas terminer la transaction c'est-à-dire ne pas faire ni commit ni rollback. La responsabilité de la transaction incombe à celui qui l’appelé.

[loustalet]

Merci pour la réponse, j'en déduis donc que c'est à mon applicatif c# de commencer et terminer la transaction?
Avez-vous une explication à me fournir ? je pensais que la transaction incombait au sgbd
Merci

[mnitu]

Une procédure est appelée pour faire son job. Cette procédure ne sait strictement rien sur les frontières de la transaction qui a été initiée avant son appel. De plus elle ne sait strictement rien non plus sur ce qui convient de faire en cas d’une exception inattendue, elle sait seulement gérer une exception inévitable ou regrettable. C’est seulement l’appelant de la procédure qui sait quand la transaction a commencé, quand elle se finit et ce qu’il convient de faire en cas d’échec de la procédure appelée.

Parfois les programmeurs pensent que certaines procédures sont en top et qu’elles définissent les transactions et y ajoutent la gestion des erreurs inattendues et la gestion de la transaction. Mais, souvent, y compris ces procédures sont assemblées dans des transactions plus générales qui automatisent des workflows plus complexes.

[loustalet]

Super, merci pour ces explications.
Je corrige mon code.
Bon we