Discussion :

[Sarbacane]

Salut,
certaines implémentations et/ou extensions (langages) du standard SQL permettent d'initier une transaction au sein d'une Procédure stockée. C'est le cas du langage Transact SQL associé au Microsoft SQL Server.
J'aimerais savoir s'il est possible d'en faire autant au sein d'un Stored Procedure du SGBDR Interbase.
Merci d'avance.

[ostaquet]

L'initialisation d'une transaction dans une Stored Procedure est loin d'être une bonne idée car l'idée même d'une Stored Procedure c'est qu'elle peut être appelée par plusieurs fonctions.

Tu risquerais donc d'initier plusieurs transactions alors qu'une seule est nécessaire pour une opération qui requiert plusieurs fois une même Stored Procedure.

De même qu'on ne mets JAMAIS un commit dans une Stored Procedure ou un Trigger. Cela ne servirais plus à rien d'avoir le concept de transaction dans les SGBD.

[Sylvain James]

Non sous Interbase, c'est le client qui a initié la procédure stockée ou le trigger qui est responsable de sa validation ou de son annulation. Donc l'intégralité des opérations à l'intérieur de la procédure stockée est considérée comme une seule opération atomique, à annuler ou valider.

[Sarbacane]

... Cela ne servirais plus à rien d'avoir le concept de transaction dans les SGBD.

Et pourtant certains SGBD s'amusent a le faire ;-)

... Donc l'intégralité des opérations à l'intérieur de la procédure stockée est considérée comme une seule opération atomique, à annuler ou valider.

Merci Sylvain pour ces nouvelles on ne peut plus claires et rassurantes.

Dans ces conditions (d'atomicité) est ce que InterBase se charge (automatiquement) de la gestion des "situations de concurence"? ou c'est au programmeur de pourvoir aux méchanismes de synchronisation (semaphores ,veroux...)?
Le choix adéquat du niveau d'isolation d'une transaction nous dispense t - il de ces taches de sychronisation?
Je m'explique:
Supposons qu' une Stored Procedure fasse appel à une série de UPDATE, DELETE, INSERT et autres GEN_ID(...) avant d'executer une requette finale.
Supposons ensuite que plusieurs clients fassent (preceque simultanément chacun dans sa propre transaction) appel à cette Stored Procedure.
Supposons en fin qu'au moins un client se plante sans avoir eu le temps de faire un COMMIT ou un ROLLBACK.
Quelle est dans ces conditions le comportement standard de Interbase? Que doit faire le programmeur pour garantir l'intégrité de son systeme?
Merci d'avance!

[jibe74]

salut,

Je relance la question intéressante de Sarbacane... Le fait qu'il n'ait pas obtenu de réponse me laisse sceptique : d'une part je suis étonné que personne ne puisse au moins émettre des hypothèses sur le sujet (c'est quand même vachement important pour des développements sous IB/FB tournant en prod !) et d'autre part, je ne crois pas que la réponse soit contenue dans les posts précédents...

Bien sûr, on pourrait supposer que l'atomicité des PS garantit un comportement correct lors d'accès concurrents, dépendant du niveau d'isolation choisi. Si cela va sans dire, pourquoi ne pas le dire ? Cela laisse un doute aux nouveaux utilisateurs de IB/FB comme moi...

Mais par ailleurs, le fait que le COMMIT ou le ROLLBACK doive être fait de manière externe peut laisser effectivement imaginer qu'un client ne fasse jamais ni l'un ni l'autre. Que va faire le SGBD dans ce cas ? Normalement, une transaction resterait indéfiniment en cours dans ce cas. Un timeout l'arrête-t-il ?

D'ailleurs, qui se charge de débuter cette transaction ? D'un côté on peut se dire que c'est fait automatiquement lors de l'appel de la procédure stockée, comme pour toute autre opération simple et atomique, mais par ailleurs, il paraitrait logique que celui qui l'a initialisée y mette fin lui-même, et donc réciproquement que ce soit à celui qui doit l'annuler ou la valider de la démarrer...

Merci de bien vouloir éclairer notre lanterne

[Barbibulle]

Bien sûr, on pourrait supposer que l'atomicité des PS garantit un comportement correct lors d'accès concurrents, dépendant du niveau d'isolation choisi. Si cela va sans dire, pourquoi ne pas le dire ? Cela laisse un doute aux nouveaux utilisateurs de IB/FB comme moi...

Ce n'est pas la PS mais la transaction qui garantie l'intégritée des données.
Bien choisir le type de transaction en fonction des type de traitements est importants pour éviter des deadlock.

Mais par ailleurs, le fait que le COMMIT ou le ROLLBACK doive être fait de manière externe peut laisser effectivement imaginer qu'un client ne fasse jamais ni l'un ni l'autre. Que va faire le SGBD dans ce cas ? Normalement, une transaction resterait indéfiniment en cours dans ce cas. Un timeout l'arrête-t-il ?

Non pas de time out, si le client plante vraiment sans pouvoir effectuer un commit ou rollback la transaction tombe dans les limbes.

les limbes : [au pluriel] En théologie, lieu où les âmes des justes se trouvaient avant la venue du Christ et où vont les âmes des enfants morts avant le baptême.• Etre dans les limbes: être dans un état vague, confus.

En d'autre termes, elle n'est ni validée ni annulée et donc tout ce qui a pu être fait à l'interieur n'est pas pris en compte. mais n'est pas effacé non plus de la base. En général un backup/restore fait le mennage et on peux demander l'élimination des transactions dans les limbes. Il me semble qu'on peut également les lister et décider de leurs sort (valider/annuler) avec un outils d'administration mais je n'en suis pas certain.

D'ailleurs, qui se charge de débuter cette transaction ?

Le client. Toujours le client. Car c'est lui également qui décide de la validation ou l'annulation de celle ci.

D'un côté on peut se dire que c'est fait automatiquement lors de l'appel de la procédure stockée, comme pour toute autre opération simple et atomique, mais par ailleurs, il paraitrait logique que celui qui l'a initialisée y mette fin lui-même, et donc réciproquement que ce soit à celui qui doit l'annuler ou la valider de la démarrer...

Sous Delphi/BC++ en utilisant les composants d'accès standards (IBX, ODBC, BDE, ect) le plus souvant c'est transparent pour le programmeur.
Lors de l'ouverture d'une requete, automatiquement une transaction est ouverte (s'il elle ne l'était pas) et ensuite c'est là que ca peux être différents c'est la fermeture.
En général la transaction est fermée automatiquement en utilisant commit par defaut dès lors qu'il n'y a plus de dataset d'ouvert utilisant cette transaction.
Mais bien entendu il est préférable lorsque c'est possible d'utiliser des transactions différentes pour chacuns de vos traitements. Et de les commiter ou rollback explicitement.

[jibe74]

Salut,

Merci beaucoup pour ta réponse, Barbibulle. Et désolé de ne pas t'avoir témoigné ma gratitude plus tôt, mais un planning débordant ne m'a pas laissé le temps de repasser avant ce matin...

Tes explications sont très claires, et confirment donc bien qu'IB/FB s'utilisent comme n'importe quel SGBD normal, tel qu'on a appris cela à l'école (enfin, pour ceux qui y ont été ) : c'est toujours le client qui dirige les transactions.

Reste la question des transactions qui "tombent dans les limbes", comme tu dis (j'adore l'image !) et qui m'ont toujours chagriné. En effet, sauf si le SGBD les termine d'office par un timeout ou tout autre artifice non standard, elles maintiennent certains blocages. Mais bon, c'est le revers de la médaille, et les solutions parfois proposées pour l'éviter ont généralement aussi des inconvénients...