pas trop d'accord avec le timeout à 0.
il n'est pas recommandé de l'utiliser, car en cas de lock sur la table, la requête, qui risque elle-même de faire un lock, ne va jamais expirer, et ainsi on fini par locker l'ensemble de la base et tout planter.
il vaut mieux faire un choix, et choisir la plus grande valeur parmis les trois suivantes :
- temps de réponse maximum autorisé (pour une application client/serveur, par exemple, 5 secondes c'est le bout du monde)
- temps d'exécution à partir duquel on estime que la requête sera annulée par l'utilisateur
- interval entre deux lancements de gros traitements succeptibles de provoquer ce comportement
=> En effet, pour une GUI "end user", il est important d'avoir un temps de réponse très rapide. au bout de quelques secondes sans résultat, pour une simple consultation par exemple, on estime que l'utilisateur est "autorisé" à jeter son pc par la fenêtre s'il n'a toujours pas le résultat. pour certain types d'application, on utilisera donc un timeout très rapide : il vaut mieux planter proprement et dire à l'utilisateur qu'en raison d'une forte charge, il ne peut pas accéder à la fonction, plutôt que de laisser tourner le truc 15 minutes (et l'empêcher de faire autrechose) avant de péter parceque de toute façon ça doit péter.
=> passé un certain délai, à nouveau, l'utilisateur est en droit de penser que l'application est plantée, et donc tout fermer "sauvagement". il est donc important de préférer produire une erreur propre avant.
=> enfin, pour un gros batch où l'utilisateur sait que ça va durer très longtemps, il faut faire attention. par exemple, un batch qui se lance toutes les heures devra impérativement mettre moins d'une heure à tourner, sans quoi on risque d'exploser le serveur au bout de quelques heures.
bref, le "timeout=0" ne répond à aucun de ces trois points. et le dernier est pourtant très important, puisque son non respect peut entraîner un plantage grave du système, et l'impossibilité de travailler pendant un certain temps, voir même des pertes de données (genre sur un système transactionnel, on peut supposer que tout le monde va bloquer au moment du commit parcequ'un lock sur une table les empêche de terminer la transaction... un reboot "intempestif" du serveur pour cause de surcharge -dead locks, etc.- va donc entraîner la perte de toutes les transactions en cours, ce qui peut rapidement correspondre à des volumes importants si l'application est multi-utilisateurs.
bref, dans la doc c'est très bien explique.
donc pour une requête qui met entre 30 et 60 secondes, on peut mettre arbitrairement un timeout à 120 secondes. cela reste suffisament grand pour garantir que la requête fonctionne dans le cas "normal", mais ça garanti aussi qu'elle ne va pas tourner indéfiniment en cas de problème.