Malheureusement, Settimeout n'est pas implémenté pour JDBC / Postgres. Y a-t-il une façon de simuler ou de contourner cela? Fonctionnellement, je veux exécuter la requête et la pause alors si elle prend plus de plus que n secondes p>
4 Réponses :
Un moyen pourrait être d'essayer d'exécuter la requête dans une classe de minuterie. Jeter une exception si la minuterie se termine sans une valeur renvoyée. P>
hibernate et JDO a > fournir une telle construction. Peut-être qu'ils seraient peut-être bonnes alternatives pour vous. P>
Vous devez faire attention à la manière dont cela est mis en œuvre; Si vous avez mal fait, vous vous retrouvez avec de nombreux threads bloqués tenant des connexions SQL qui sont simplement ignorées. Une partie de la question est que vous ne pouvez pas forcer un fil à jeter une exception si c'est au milieu de faire quelque chose.
Le "relevé_timeout" ressemble à ce que vous voulez.
SET statement_timeout TO 1000; -- for a second <your_query_here>; RESET statement_timeout; -- reset
Vous ferez mieux d'utiliser réinitialiser énoncé_timeout; Une fois la requête terminée - au cas où il y a une valeur par défaut ...
Testé cela sur PGADMIN3. Seulement travaillé lorsque l'instruction SET_TIMEOUT est exécutée séparément de la requête réelle. Lorsqu'il est exécuté ensemble, PGADMIN3 utilise quelle que soit la valeur du délai d'attente déjà définie et qu'il n'utilise pas celui fourni avec la requête.
Alternativement, utilisez Définition de l'instruction locale sur 1000, ce qui limite la portée à la transaction en cours. De cette façon, vous n'avez pas à vous soucier de la réinitialiser, il vous suffit de limiter la portée de la transaction.
Pour que cela soit plus clair, je viens d'écrire ma propre réponse; N'hésitez pas à mettre à jour le vôtre.
Et si vous deviez utiliser C3P0 pour votre DataSource? Il possède de nombreux options configurables et pour des bases de données et des réseaux courants, par exemple des acquirères, de l'acquireurRetryDelay et de BreakafteracQuireFailure. P>
L'utilisation du mot clé local limite la portée de la relève_timeout à la transaction en cours. De cette façon, si quelque chose ne va pas (par exemple, il est temps de sortir) Le délai d'attente est réinitialisé.
J'ai trouvé cette question et la réponse utile également pour un problème Python / Psycopg2 que j'ai rencontré. Psycopg2 semble avoir autorisé le réglage du délai d'attente au moment de la connexion, mais cette interface était abstraite dans mon cas. Ajout de ce commentaire pour profiter aux autres les recherches.