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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
William Marie
"MCI" a écrit dans le message de news: 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" <enleverlesO.OmcO@OmclaveauO.com> a écrit dans le message de news:
467ca32f$0$27383$ba4acef3@news.orange.fr...
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" a écrit dans le message de news: 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
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
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.
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
"MCI" a écrit dans le message de news: 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) ====================================
"MCI" <enleverlesO.OmcO@OmclaveauO.com> a écrit dans le message de news:
467deb43$0$27393$ba4acef3@news.orange.fr...
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)
====================================
"MCI" a écrit dans le message de news: 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
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
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."
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
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 ***********************
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 ***********************
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
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 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......"
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
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 ***********************
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 ***********************
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
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 ?
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 ?
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 ?
