différence de pose de verrou LOCK table

Version imprimable

22/04/2009, 10h08
canardpc

différence de pose de verrou LOCK table

Bonjour,

mon problème est de savoir si dans une procédure stockée de poser un LOCK TABLE maTable IN SHARE ROW EXCLUSIVE MODE; bloque le traitement de la procédure et empeche un autre locj de ce type ?

Je m'explique la procédure peut être appelé en simultanée et plusieurs instructions sont faites sur maTable (select pour vérifier si une donnée est présente ensuite un insert ou un update.. ) somme tout banal.

J'ai mis LOCK TABLE maTable IN EXCLUSIVE MODE; mais c'est à priori un peu trop mais je ne suis pas sur qu'un LOCK TABLE maTable IN SHARE ROW EXCLUSIVE MODE empeche de reposer LOCK TABLE maTable IN SHARE ROW EXCLUSIVE MODE par un autre appel en simultanée ???

D'apres la doc Oracle cela semble bon mais ce n'est pas si clair que celam le lock SRX semble est correcte et les insert ou update de la procédure ne doivent pas laché se lock!

Merci d'avance
22/04/2009, 10h19
mnitu

T'as fait un petit test sur le lock en shared row exclusive mode ?
22/04/2009, 10h53
pachot

Bonjour,

Citation:

je ne suis pas sur qu'un LOCK TABLE maTable IN SHARE ROW EXCLUSIVE MODE empeche de reposer LOCK TABLE maTable IN SHARE ROW EXCLUSIVE MODE par un autre appel en simultanée

Oui, d'aprés la doc (http://download.oracle.com/docs/cd/B...t.htm#BABCJIAJ): SRX prohibits SRX

Maintenant par rapport à ton besoin:

1-

Citation:

la procédure peut être appelé en simultanée

Si tu utilise un lock exclusif (comme SHARE ROW EXCLUSIVE MODE ou EXCLUSIVE MODE), les appels simultanés seront en fait sérialisés sur ce verrou.

2-

Citation:

select pour vérifier si une donnée est présente ensuite un insert ou un update

Un simple select for update permet celà: les données que tu as lues ne seront pas modifiées par une session concurrente. Par contre, celà n'empêche pas des insertions concurrentes. A toi de voir si tu veux empêcher celà.
Un exemple: tu as 20 places dans un avion et tu as une table qui enregistre une ligne par réservation. Tu fais un select qui te dit qu'il reste une place libre, alors tu la reserve. Mais si entre temps une autre session a fait la même chose tu a fait du surbooking.

Pour prévenir celà,
- soit tu empêches tout DML sur la table (LOCK TABLE ... IN SHARE MODE)
Celà empêche toute réservation concurrente, mais pas la consultation du nombre de place libre.
- soit tu peux vérouiller un enregistrement père, genre select for update sur l'avion. Et tu garantis que toute nouvelle réservation fait celà.
Celà ne bloque que les réservations sur le même avion

Cordialement,
Franck.
22/04/2009, 14h25
canardpc

Ok merci pour le lien et les réponses.

Cela résout mon pb.
sinon pour tester je ne peux pas faire des tests concluant je n'ai pas l'environnement et les outils pour le faire.

Citation:

Envoyé par pachot

Bonjour,

Oui, d'aprés la doc (http://download.oracle.com/docs/cd/B...t.htm#BABCJIAJ): SRX prohibits SRX

Maintenant par rapport à ton besoin:

1- Si tu utilise un lock exclusif (comme SHARE ROW EXCLUSIVE MODE ou EXCLUSIVE MODE), les appels simultanés seront en fait sérialisés sur ce verrou.

2- Un simple select for update permet celà: les données que tu as lues ne seront pas modifiées par une session concurrente. Par contre, celà n'empêche pas des insertions concurrentes. A toi de voir si tu veux empêcher celà.
Un exemple: tu as 20 places dans un avion et tu as une table qui enregistre une ligne par réservation. Tu fais un select qui te dit qu'il reste une place libre, alors tu la reserve. Mais si entre temps une autre session a fait la même chose tu a fait du surbooking.

Pour prévenir celà,
- soit tu empêches tout DML sur la table (LOCK TABLE ... IN SHARE MODE)
Celà empêche toute réservation concurrente, mais pas la consultation du nombre de place libre.
- soit tu peux vérouiller un enregistrement père, genre select for update sur l'avion. Et tu garantis que toute nouvelle réservation fait celà.
Celà ne bloque que les réservations sur le même avion

Cordialement,
Franck.
22/04/2009, 17h08
mnitu

Citation:

Envoyé par canardpc

...
sinon pour tester je ne peux pas faire des tests concluant je n'ai pas l'environnement et les outils pour le faire.

Un simple sqlplus ça suffit. Et il est toujours disponible sur Apex en ligne.
Il y a aussi un package DBMS_LOCK qui peut être utilisé pour les verrous utilisateur.