Accès concurrent sur un cursor "For update"

Bonjour Tout le monde,

Le "For update [of]" d'un cursor permet de verrouiller l'accès aux données aux autres utilisateurs. Mes questions sont les suivantes :

- Lorsque j'utilise "FOR UPDATE OF monchamp", l'accès est autorisé au lmd sur les autres champs n'est ce pas ?
- Dans le même sens que la question précédente : le verrouillage se fait-il au niveau de la ligne courante ou au niveau de l'ensemble des données concernées par le curseur ?
- L'accès aux données est-il verrouillé pour une autre instance du même utilisateur courant

- Peut-on utiliser l'expression "WHERE CURRENT OF" sur un curseur "normal" ?

Merci d'avance pour vos réponses. :D
Alex

J'ai la réponse à ma question concernant le "..WHERE CURRENT OF.." :?

Code:

---

1 2	Error(7,22): PLS-00404: curseur 'C_UPDATE' doit être déclaré avec FOR UPDATE pour utilis. avec CURRENT OF

---

Cependant, concernant le verrouillage des données avec une autre instance de l'utilisateur courant, avez-vous une réponse ?

Le lock se fait par instance peu importe l'utilisateur
=> avec le même utilisateur ton enregistrement sera vérouillé.

Pour t'en rendre compte :
- tu ouvres un SQL*Plus, tu te connectes avec ton user1, tu fais un select for update
- tu ouvres un second SQL*Plus, tu te connectes une nouvelle fois avec ton user1 et tui essaies de faire un update sur la ligne que tu as vérouillé
=> SQL*Plus ne te rendra la main que lorsque tu auras déverouillé la première instance

Merci plaineR pour ta réponse :D
Je comprends ce que tu as expliqué.

Exemple :
- Une 1ère session lance une Procédure1 en ".. For UPDATE", qui met à jour des lignes, sans fermeture du curseur.
- Une autre session (du même user ou d'un autre) lance une Procédure2 qui met également à jour ces mêmes lignes.

Questions :
- Si la Procédure2 comporte un WAIT assez élevé pour que la Procédure1 se termine, la Procédure2 arrive à accéder en modification aux mêmes données, malgré la non-fermeture du curseur de la Procédure1 ?
- Lorsqu'un curseur n'est pas explicitement refermé, que se passe-t-il pour sa durée de vie ?

Citation:

---

Le lock se fait par instance peu importe l'utilisateur

---

Moi, je pense qu'on peut préciser en disant que le verrouillage se fait par transaction (pas par utilisateur et même pas par session puisqu'une session peut avoir 2 transactions en cours avec les transactions indépendantes: d'où des cas parfois très tordus d'auto-deadlock dans une même session ...).

Citation:

---

Si la Procédure2 comporte un WAIT assez élevé pour que la Procédure1 se termine, la Procédure2 arrive à accéder en modification aux mêmes données, malgré la non-fermeture du curseur de la Procédure1 ?

---

Ici, ce qui compte c'est que Procédure1 fait COMMIT ou ROLLBACK: à ce moment, les verrous sont libérés que le curseur soit ouvert ou non.

Citation:

---

Lorsqu'un curseur n'est pas explicitement refermé, que se passe-t-il pour sa durée de vie ?

---

je crois que Oracle permet de garder les curseurs ouverts après COMMIT mais c'est risqué... D'où certains problèmes ORA-1555 lorsqu'on continue d'utiliser un curseur après COMMIT (FETCH across COMMIT).

Merci pifor pour tes réponses,:D

Citation:

---

Envoyé par pifor

puisqu'une session peut avoir 2 transactions en cours avec les transactions indépendantes: d'où des cas parfois très tordus d'auto-deadlock dans une même session ...).

---

Oui c'est à ce cas tordu que je pensais en posant ma question.
Parce qu'un multithread d'une même session portant sur les mêmes données peut avoir lieu. C'est pour çà que je me posais la question de savoir si thread2 avait accès aux données de thread1 dans la même session...Bref..

Citation:

---

Envoyé par pifor

Ici, ce qui compte c'est que Procédure1 fait COMMIT ou ROLLBACK: à ce moment, les verrous sont libérés que le curseur soit ouvert ou non.

---

ok, j'ai compris :D

Citation:

---

Envoyé par pifor

Oracle permet de garder les curseurs ouverts après COMMIT mais c'est risqué... D'où certains problèmes ORA-1555 lorsqu'on continue d'utiliser un curseur après COMMIT (FETCH across COMMIT).

---

Après un commit, donc après la fermeture d'un curseur on peut encore potentiellement s'en servir (??j'ai compris ou pas??) ?
Une dernière question : un curseur portant sur par exemple 150000lignes non fermé, engendre-t-il une sorte de débordement du tempon mémoire ?(ou autre...)

Citation:

---

Parce qu'un multithread d'une même session portant sur les mêmes données peut avoir lieu. C'est pour çà que je me posais la question de savoir si thread2 avait accès aux données de thread1 dans la même session...Bref..

---

Dans Oracle, le multithreading n'a pas grand chose à voir avec les transactions autonomes: une transaction autonome prend la main alors qu'une autre est déjà démarrée: de ce point de vue c'est le même thread ou processus. Oracle utilise le multithreading en général avec l'option shared servers (ex-MTS) ou par défaut sous Windows pour tout types de connections.

Citation:

---

Après un commit, donc après la fermeture d'un curseur on peut encore potentiellement s'en servir (??j'ai compris ou pas??) ?

---

Oui, tout à fait, mais ce n'est pas conseillé ...;)

Citation:

---

Une dernière question : un curseur portant sur par exemple 150000 lignes non fermé, engendre-t-il une sorte de débordement du tempon mémoire ?(ou autre...)

---

Un débordement non, mais il va continuer d'utiliser des ressources d'abord dans le shared pool (ça c'est sûr) et peut-être dans le buffer cache (pas sûr).

Que de réponses ! :D

Merci pour tes précisions pifor :mouarf: