Rendre une procédure "atomique"

Bonjour,

le delete sur des grosses tables étant très long, je me suis créé une petite procédure qui l'effectue en réalisant une copie dans une table temporaire "g_nomTableTempDelete"

Code:

---

1 2 3 4 5 6 7 8 9

PROCEDURE deleteFromTable (p_nomTable IN VARCHAR2, p_deleteWhere IN VARCHAR2) IS BEGIN dropTableIfExists(g_nomTableTempDelete); EXECUTE IMMEDIATE ('CREATE TABLE ' || g_nomTableTempDelete || ' AS SELECT * FROM ' || p_nomTable || ' WHERE NOT (' || p_deleteWhere || ')'); EXECUTE IMMEDIATE ('TRUNCATE TABLE ' || p_nomTable); EXECUTE IMMEDIATE ('INSERT INTO ' || p_nomTable || ' SELECT * FROM ' || g_nomTableTempDelete); EXECUTE IMMEDIATE ('DROP TABLE ' || g_nomTableTempDelete); END;

---

Mon problème est le suivant : j'ai peur que si la procédure est appelée par deux utilisateurs en même temps, on se retrouve avec la table temporaire du premier utilisateur effacée par le second...
J'aimerais donc trouver un moyen de rendre la procédure "atomique". Mais puisque les instructions DDL font un commit, je pense que ça ne changera rien de la faire exécuter dans une transaction autonome... Il me faudrait une sorte de sémaphore, je ne sais pas trop comment faire...

Si tu vires la première ligne, cela fonctionnerait comme tu veux non ?

Je suis obligé de laisser un drop, car j'ai eu le cas où un programme plantait en cours de route, du coup la table n'est jamais supprimée, et quand on redémarre le programme ça met une erreur car la table existe déjà.

Mais même si je vire cette ligne, je pense que j'aurai toujours le problème possible, dans le cas où l'utilisateur 2 va me faire un "create table", alors que l'utilisateur 1 est en train d'exécuter la procédure, et a déjà fait le create table mais n'est pas encore parvenu jusqu'au drop....

Citation:

---

Envoyé par brassouille

Mais même si je vire cette ligne, je pense que j'aurai toujours le problème possible, dans le cas où l'utilisateur 2 va me faire un "create table", alors que l'utilisateur 1 est en train d'exécuter la procédure, et a déjà fait le create table mais n'est pas encore parvenu jusqu'au drop....

---

Non tu ne peux pas créer 2 tables avec le même nom sous un même schéma ;)

Il y a plusieurs solutions pour t'en sortir :
- passer par des temporary table
- ajouter le nom du user au nom de table temporaire
- indiquer dans une autre table que cette procédure est en cours d'exécution
- ...

En fait pour la temporary table :
- je ne peux pas la créer AVANT d'exécuter la procédure vu que je ne connais pas son schéma
- si je la crée PENDANT la procédure, j'aurai toujours le même problème qu'actuellement, je risque de faire un create alors qu'un autre create a déjà été fait par un accès concurrent.

Pour le nom du user ça n'ira pas car on utilise toujours le même user, par contre je dois pouvoir faire ça en récupérant un identifiant de transaction ou quelque chose comme ça :)

Pour ta troisième solution, oui je pourrais, ça fait effectivement office de sémaphore, mais ça m'embête un peu de créer une table "bidon" chez le client juste pour des raisons d'optimisation de code...

Bon, je vais tenter de trouver un identifiant de transaction alors, merci pour ton aide :)

Par contre je suis en train de me dire que si un programme plante ou est arrêté brutalement, je n'effacerai jamais la table temporaire qu'il aura créée, si je l'ai suffixée par un identifiant de transaction... :(

le fait de créer ta table bidon te permet justement de gerer ca ....

c'est beuacuop utilisé ce priincipe dans les automatisations de script avec conditions ...

tu peux aussi creer un fichier temoin ....

Mais si je mets à jour un marqueur "encours" dans la table bidon, puis que mon programme plante et que je ne retire jamais ce marqueur, comment je peux retirer ce marqueur par la suite?

Là il faut que tu gères des exceptions.

Je pensais plutôt si mon programme est interrompu (ctrl + alt + suppr, panne de courant etc...) avant d'avoir fait le drop. Aucune exception n'est lancée. Dans ce cas, j'aurai créé ma table (qui aura été commitée automatiquement) mais je ne vais jamais la supprimer.

Je peux peut-être faire quelque chose comme ça (encours étant lu/écrit dans une table)

Code:

---

1 2 3 4 5 6

- tantque not encours, wait - encours := true - si la table temporaire existe déjà, la supprimer - appeler ma procédure dans une autonomous transaction - encours := false - commit

---

Comme ça, si jamais le programme est interrompu brutalement, le "encours := true" sera rollbacké automatiquement. Vous en pensez quoi? ça vous parait propre de boucler sur un wait comme ça? j'ai peur que ça me fasse des milliers de requêtes select pour rien, et que ça fasse ramer le serveur...