Je reçois parfois l'exception suivante:
com.ibm.db2.jcc.b.gm: [JCC] [T4] [2030] [3.50.152] Une erreur de communication s'est produite lors des opérations sur la prise sous-jacente de la connexion, le flux d'entrée de socket, ou flux de sortie de socket. Erreur Emplacement: Répondre.fill (). Message: Réinitialisation de la connexion. ErrorCode = -4499, SQLSTATE = 08001
Le problème est que le code s'exécute avec succès depuis un certain temps, puis soudainement, je reçois cette exception. Cependant, il fonctionne parfaitement lorsque j'exécute le code à nouveau.
Quelqu'un pourrait-il s'il vous plaît dites-moi ce qui pourrait se tromper et me fournir des indications pour résoudre ce problème?
4 Réponses :
Il semble que votre connexion soit chronométrée. Je ne suis pas vraiment là où se trouve le problème. Cela pourrait être avec la connexion à votre serveur DB. Je suis désolé je ne peux pas vous aider davantage, mais j'espère que cela vous aidera.
Il s'agit d'un signe de ne pas fermer / libérer des ressources JDBC. Vous devez acquérir enfin code> du bloc essayer bloc du même bloc de méthode que vous les avez acquis. Par exemple, Connection connection = null;
Statement statement = null;
ResultSet resultSet = null;
try {
connection = database.getConnection();
statement = connection.createStatement();
resultSet = statement.executeQuery(SQL);
// ...
} finally {
if (resultSet != null) try { resultSet.close(); } catch (SQLException logOrIgnore) {}
if (statement != null) try { statement.close(); } catch (SQLException logOrIgnore) {}
if (connection != null) try { connection.close(); } catch (SQLException logOrIgnore) {}
}
Espérons que le bloc d'essai avec les ressources en Java 7 aidera à atténuer une partie de cela à l'avenir. Bien qu'il y ait une partie de moi, des volets avec une crainte à propos de permettre aux développeurs de s'en sortir de ne pas nettoyer les ressources. Je crains que cela puisse conduire à un développement bâclé. Et puis, que se passe-t-il si ces développeurs doivent travailler sur le code de pré-JRE 7? Il suffit de penser à voix haute en réponse à votre réponse. Mais définitivement ++ sur la réponse.
@Chris: Certainement, le bras aidera beaucoup à réduire le Fermer () - enfin Boiserie. Cependant, vous pourriez également choisir JPA, ce qui, à son tour, réduit l'ensemble de la chaudière JDBC à un ONLININ.
Intéressant. Connaissez-vous des articles sur JPA vs pure JDBC. Je suppose que je viens d'expérience où les couches d'abstraction ont parfois rendu notre application pire et plus difficile à déboguer. J'ai trouvé Pure JDBC assez simple (au moins lorsque vous travaillez avec des chaînes SQL pure). Je peux voir où cela fonctionnerait mieux avec des objets. Et il gère la fermeture des ressources pour vous?
Aucun vient à l'esprit. Travailler à travers certains tutoriels de base JPA doivent bien donner de bonnes perspectives. Par exemple. Vogella.de/articles/javaperssiceapi/article.html et Eclipse.org/webols/dali . Oui, il gère de manière transparente la fermeture (ainsi que les trucs transactionnels avec commencent () et commit () lorsque vous le faites dans une EJB).
Je semble que cela puisse être causé par https://www-304.ibm.com/support/docview.wss ? uid = swg1ic63952
au moins pour nous c'est.
vérifier votre db2diag.log pour Plus tard cette semaine, nous prévoyons de passer à DB2 9.7 FixPack 3A - Récutera si cela aidé. zrc = 0x8005006d = -2147155859 = sqle_ca_built
"SQLCA a été construit et enregistré dans des composants spécifiques
contrôler
bloc. " messages d'erreur lorsque vous obtenez de telles déconnexions.
Nous sommes également récemment confrontés à cette question et cela était dû à déroutant et à des clauses avec une clause A et Rownum <. Mettre les accolades aux bons endroits résolus.
Ce post devrait être un commentaire, pas une réponse
Veuillez vous reporter à ce lien aussi bien www-01.ibm.com/support/ DOCVIEW.WSS? UID = SWG21962086 et www-01. ibm.com/support/support/docview.wsssiorid=swg21600160