procédure stockée : Verrou / accès concurrent

[florent_g]

Bonjour,

Je souhaiterais empêcher tout accès concurrent sur l'exécution d'une procédure stockée (comme le ferait un Mutex) : Si un autre appel intervient pendant son exécution je voudrait que l'appel ne lance pas l'exécution tant que le précédent n'est pas exécuté (ou ne lance rien du tout).

Est-ce quelque chose d'intégré dans Sql Server ?

merci

Florent

[elsuket]

Bonjour,

Il vous suffit pour cela de spécifier le niveau d'isolation de transaction SERIALIZABLE dès le début de votre procédure stockée, et de transactionner explicitement l'ensemble de vos requêtes :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE PROCEDURE maProcedure
	@_parametres <type_de_donnees>
AS
BEGIN
	SET NOCOUNT ON
	SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
 
	BEGIN TRY
		BEGIN TRANSACTION
 
		...
 
		COMMIT TRANSACTION
	END TRY
	BEGIN CATCH
		...
		ROLLBACK TRANSACTION
	END CATCH
END

Quel est le but de la manœuvre ?

@++

[florent_g]

Le but de la manœuvre est de corriger un dysfonctionnement ... Il semble qu'elle est appelée une deuxième fois avant la fin de l'exécution précédente, et comme elle utilise des tables intermédiaires de calcul ça ne se passe pas bien !

Merci pour la réponse, j'essaie tout de suite !

[elsuket]

Il semble qu'elle est appelée une deuxième fois avant la fin de l'exécution précédente

Dans ce cas il faudrait savoir pourquoi elle s'exécute une seconde fois.
Est-elle appelée par un job ?

@++

[florent_g]

Elle appelé par un écran utilisateur (bouton), comme il y a plusieurs écrans il peut y avoir des appels concurrents

[iberserk]

Le but de la manœuvre est de corriger un dysfonctionnement ... Il semble qu'elle est appelée une deuxième fois avant la fin de l'exécution précédente, et comme elle utilise des tables intermédiaires de calcul ça ne se passe pas bien !

Merci pour la réponse, j'essaie tout de suite !

Vous pouvez aussi penser à 'isoler' votre traitement en ajoutant une colonne alimentée par un UNIQUEIDENTIFIER propre à votre exécution... ainsi même si elle est appelée une deuxième fois les exécution sont indépendantes.
Mais peut'être n'est ce pas le but recherché?

[mikedavem]

Je me pose la question de savoir si le niveau de transaction SERIALIZABLE est vraiment adapté pour cette problématique. En effet même si ce mode permettra de bloquer l'exécution de 2 procédures simultanées elle n'empêchera pas pour autant son exécution. De plus le verrouillage fort qu'implique ce niveau d'isolation peut être pénalisant pour les autres requêtes qui seraient suceptibles d'utiliser les objets impliqués.

Il me semble que Hmira avait proposé une solution intéressante sur le sujet qui consistait à créer une table de réservation des procédures qui permettaient de fonctionner à l'instar des mutex.

++

[iberserk]

Je me pose la question de savoir si le niveau de transaction SERIALIZABLE est vraiment adapté pour cette problématique. En effet même si ce mode permettra de bloquer l'exécution de 2 procédures simultanées elle n'empêchera pas pour autant son exécution. De plus le verrouillage fort qu'implique ce niveau d'isolation peut être pénalisant pour les autres requêtes qui seraient suceptibles d'utiliser les objets impliqués.

D'ou ma question: que voulez vous faire: annuler l'execution de la même SP quand clele-ci est déjà en cours d'execution ou faire en sorte qu'en cas de 2 appels 'chevauchants' les appels soient placés en liste d'attente?

[elsuket]

Mikedavem, Iberserk,

Les questions que vous soulevez ont tout leur sens, cela dit :

Envoyé par florent_g

Elle appelé par un écran utilisateur (bouton), comme il y a plusieurs écrans il peut y avoir des appels concurrents

Il ne revient jamais à personne de gérer le verrouillage : le moteur de bases de données d'un SGBDR sait faire cela bien mieux que quiconque.

Si l'on souhaite effectuer un groupe de transactions comme une seule transaction, il suffit de le faire explicitement.

En cela je suis d'accord avec vous : le niveau d'isolation SERIALIZABLE ne répond pas proprement à la problématique.

@++