Discussion :

[dydo01]

Bonjour à Tous,

Prière de m'aider à résoudre ce problème, car je suis planté ça fait 2j .

En fait, mon problème est de tuer le verrouillage à partir d’une session « S2 » sachant qu’il a été obtenu à partir d’une session « S1 » en utilisant les fonctions du package dbms_lock

Donc « S1 » lance ces 2 instructions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
dbms_lock.allocate_unique(mon_contexte, handle);
status := dbms_lock.request(handle, dbms_lock.X_MODE, li_timeout);
 
--status = 0 ==> lock établi / status=1 :'Timeout' / status=2 : 'Deadlock' / status=3 : 'Parameter Error' / status=4 :'Lock déja obtenu' / status=5 : 'Illegal Lock Handle'

« S1 » peut libérer son propre verrouillage en utilisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
 dbms_lock.allocate_unique(mon_contexte, handle);
 status := dbms_lock.release(handle);

Mais « S2 » ne peut pas libérer le verrouillage obtenu par « S1 » en utilisant la fonction « dbms_lock.release() » ;

==> Donc mon objectif est : à partir de la session « S2 » je tue le lock obtenu à partir de la session « S1 » tout en gardant la session « S1 » en vie (càd tuer uniquement le process du lock sans tuer toute la session).

Merci d’avance pour votre aide

[mnitu]

Je ne pense pas que c'est possible parce que

RELEASE Function

This function explicitly releases a lock previously acquired using the REQUEST function

Donc qu'est-ce que vous essayez d'accomplir ?

[dydo01]

Donc qu'est-ce que vous essayez d'accomplir ?

Bonjour,

Merci mnitu pour la réponse.

En fait, je veux que la session S2 soit la session maitre, elle est toujours la prioritaire à exécuter le Bloc X.

Donc je ne veux pas que S2 attends la fin d'exécution du Bloc X par S1 ==> existe-il une instruction s'exécutant en mode NOWAIT pour assurer ce comportement.

Merci beaucoup

[mnitu]

Ca reste assez vague. Actuellement la session S1 acquiert un verrou exclusif. Ensuite probablement qu'elle exécute quelque chose. Elle pourrait peut être interroger régulièrement pour voir si la session S2 il lui demande de libérer ce verrou. Mais ...

[dydo01]

Ca reste assez vague.

je vais simplifier mon problème avec le scénario suivant:

Session S1 :
1/ faire un Lock sur un ensemble de données qu'on appelle D1
2/ Modifier D1
3/ COMMIT
4/ Release Lock

On suppose que le temps entre l'étape 3 et 4 est négligeable.

L'étape 2 (représente le bloc X) prend beaucoup de temps, et je ne veut pas utiliser le paramètre timeout de la fonction dbms_lock.request appelée à partir de S1 qui assure le comportement que vous avez mentionné :

Elle pourrait peut être interroger régulièrement pour voir si la session S2 il lui demande de libérer ce verrou.

La Session S2 represente un super user qui a la possiblité de modifier les données en 1er lieu ;
S2 sait que S1 la bloque (car dbms_lock.request executée sur S2 retourne 1)
==> donc S2 veut tuer le lock imposé par S1, et acquérir son propre lock.

[mnitu]

Vous avez donc besoin d'un sort de mécanisme d'intercommunication entre les deux sessions. Pour que la deuxième session puisse demander à la première de libérer le verrou exclusif. Et vous devez commencer par définir ce que la session S1 est supposé à faire dans ce cas, se mettre en attente, abandonner, etc.