Question SQL-server / Oracle (triggers)

Le
MCI
Bonjour !

En théorie, des triggers circulaires peuvent provoquer des étreintes
mortelles.
Savez-vous si les SGBD sus-cités sont équipés de mécanismes de protection ?
Et, si oui, savez-vous comment sont implémentés ces mécanismes ?

Merci d'avance, pour toute réponse judicieuse.

Michel Claveau
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
William Marie
Le #21852401
"MCI" 467ca32f$0$27383$
Bonjour !

En théorie, des triggers circulaires peuvent provoquer des étreintes
mortelles.
Savez-vous si les SGBD sus-cités sont équipés de mécanismes de protection
? Et, si oui, savez-vous comment sont implémentés ces mécanismes ?

Merci d'avance, pour toute réponse judicieuse.



Oui, dans le cas de SQL Server 2005. Il y a un exemple "Visualisation des
verrous mortels dans SQL Server profiler" (dans "SQL Server 2005 étape par
étape", Microsoft Press) mais il se bloque chez moi à l'étape 4 (éxécution
sans fin) et la description du phénomène n'est pas d'une pédagogie folle.
Mais enfin, bref, ça existe et ça s'analyse avec SQL Server Profiler.
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
MCI
Le #21852361
Bonjour !

Merci de l'info.

Néanmoins, ma question portait plus sur les triggers (déclencheurs), qui
peuvent se déclencher mutuellement (ou circulairement), et bloquer le sgbd,
sans utiliser le moindre verrou.

Par exemple simpliste :
- deux tables, A et B
- A.beforeinsert insère un enregistrement dans B
- B.beforeinsert insère un enregistrement dans A
Comme tout se déclenche avant insertion, il n'y a pas de verrous utilisés,
donc, pas de verrou mortel. C'est pour ça que je préférais le terme étreinte
mortelle.


En fait, je cherche à implémenter cette protection dans un sgbd (maison), en
mémoire, monoposte, monoapplication, mais avec des déclencheurs qui peuvent
être circulaires.

Le problème est compliqué par le fait que je gère des triggers au niveau de
l'update des champs, sans verrous explicites, et sans que rien n'empêche(*),
pour l'instant, des triggers circulaires, entraînant une boucle infinie.

(*) sauf les limites de récursion/réentrance du langage sous-jacent.


@-salutations

Michel Claveau
William Marie
Le #21852351
"MCI" 467deb43$0$27393$
Bonjour !

Merci de l'info.

Néanmoins, ma question portait plus sur les triggers (déclencheurs), qui
peuvent se déclencher mutuellement (ou circulairement), et bloquer le
sgbd, sans utiliser le moindre verrou.



Merci pour cette explication du problème. Là j'ai tout compris, mais je
ne suis pas assez câlé pour proposer une solution. Les enfermer dans des
blocs conditionnels (si c'est possible) ?
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
nobody
Le #21843561
MCI a écrit :
Bonjour !

Merci de l'info.

Néanmoins, ma question portait plus sur les triggers (déclencheurs), qui
peuvent se déclencher mutuellement (ou circulairement), et bloquer le sgbd,
sans utiliser le moindre verrou.

Par exemple simpliste :
- deux tables, A et B
- A.beforeinsert insère un enregistrement dans B
- B.beforeinsert insère un enregistrement dans A
Comme tout se déclenche avant insertion, il n'y a pas de verrous utilisés,
donc, pas de verrou mortel. C'est pour ça que je préférais le terme étreinte
mortelle.


En fait, je cherche à implémenter cette protection dans un sgbd (maison), en
mémoire, monoposte, monoapplication, mais avec des déclencheurs qui peuvent
être circulaires.

Le problème est compliqué par le fait que je gère des triggers au niveau de
l'update des champs, sans verrous explicites, et sans que rien n'empêche(*),
pour l'instant, des triggers circulaires, entraînant une boucle infinie.

(*) sauf les limites de récursion/réentrance du langage sous-jacent.


@-salutations

Michel Claveau






voir http://traduc.postgresqlfr.org/pgsql-8.1.2-fr/triggers.html
et entre autre :
"Il n'est pas possible actuellement d'écrire une fonction déclencheur
dans le langage de fonction SQL"

"Si une fonction déclencheur exécute des commandes SQL, alors ces
commandes peuvent relancer des déclencheurs. On appelle ceci un
déclencheur en cascade. Il n'y a pas de limitation directe du nombre de
niveaux de cascade. Il est possible que les cascades causent un appel
récursif du même déclencheur ; par exemple, un déclencheur INSERT
pourrait exécuter une commande qui insère une ligne supplémentaire dans
la même table, entraînant un nouveau lancement du déclencheur INSERT. Il
est de la responsabilité du programmeur d'éviter les récursions infinies
dans de tels scénarios."

le problème est donc SQL
Fred Brouard - SQLpro
Le #21843541
MCI a écrit :
Bonjour !

En théorie, des triggers circulaires peuvent provoquer des étreintes
mortelles.
Savez-vous si les SGBD sus-cités sont équipés de mécanismes de protection ?
Et, si oui, savez-vous comment sont implémentés ces mécanismes ?

Merci d'avance, pour toute réponse judicieuse.

Michel Claveau





les deadlock sont détecté de manière automatique dans SQL Server par
time out et l'une des transaction y participant (par défaut la plus
légère) est annulée (ROLLBACK).

pour le cas des triggers, vous pouvez piloter les paramètres suivants :
- triggers récursif (on/off) au niveau de chaque base de données
- trigger imbriqués, c'est à dire ping-pong, au niveau du serveur

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
nobody
Le #21843521
Fred Brouard - SQLpro a écrit :

les deadlock sont détecté de manière automatique dans SQL Server par
time out et l'une des transaction y participant (par défaut la plus
légère) est annulée (ROLLBACK).




ou par écroulement du calculateur avant sous la charge de calcul induite
par les deadlocks ?

la gestion des deadlocks par time-out c'est du style
"- comme savez vous que le véhicule est trop chargé?"
"- ben si le véhicule n'est pas arrivé après un certain temps on
décharger le plus petit colis et on attends de nouveau un certain temps
avant de décharger a nouveau le plus petit colis......"

c'est bourrin comme méthode
Fred Brouard - SQLpro
Le #21843501
Fred Brouard - SQLpro a écrit :
MCI a écrit :
Bonjour !

En théorie, des triggers circulaires peuvent provoquer des étreintes
mortelles.
Savez-vous si les SGBD sus-cités sont équipés de mécanismes de
protection ? Et, si oui, savez-vous comment sont implémentés ces
mécanismes ?

Merci d'avance, pour toute réponse judicieuse.

Michel Claveau





les deadlock sont détecté de manière automatique dans SQL Server par
time out et l'une des transaction y participant (par défaut la plus
légère) est annulée (ROLLBACK).

pour le cas des triggers, vous pouvez piloter les paramètres suivants :
- triggers récursif (on/off) au niveau de chaque base de données
- trigger imbriqués, c'est à dire ping-pong, au niveau du serveur

A +




j'ajouterais, le niveau de récursion maximale est de 32. Au dela exception.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
nobody
Le #21843491
Fred Brouard - SQLpro a écrit :
Fred Brouard - SQLpro a écrit :
MCI a écrit :
Bonjour !

En théorie, des triggers circulaires peuvent provoquer des étreintes
mortelles.
Savez-vous si les SGBD sus-cités sont équipés de mécanismes de
protection ? Et, si oui, savez-vous comment sont implémentés ces
mécanismes ?

Merci d'avance, pour toute réponse judicieuse.

Michel Claveau





les deadlock sont détecté de manière automatique dans SQL Server par
time out et l'une des transaction y participant (par défaut la plus
légère) est annulée (ROLLBACK).

pour le cas des triggers, vous pouvez piloter les paramètres suivants :
- triggers récursif (on/off) au niveau de chaque base de données
- trigger imbriqués, c'est à dire ping-pong, au niveau du serveur

A +




j'ajouterais, le niveau de récursion maximale est de 32. Au dela exception.

A +




la limite a 32 ne change rien a la méthode bourrin cela revient a réagir
qu'une voiture est en surcharge lorsque il y a plus de 32 passagers :-)

32 récursions donne combien de triggers avant qu'il y est exception ?
Publicité
Poster une réponse
Anonyme