Java JDBC: Reply.fill()

me sale el siguiente excepción a veces:Java JDBC: Reply.fill()

com.ibm.db2.jcc.b.gm: [CCM] [T4] [2030] [11211] [ 3.50.152] Se produjo un error de comunicación durante las operaciones en el zócalo subyacente de la conexión, la corriente de entrada del zócalo, o la corriente de salida del zócalo. Ubicación del error: Reply.fill(). Mensaje: restablecimiento de la conexión. ERRORCODE = -4499, SQLSTATE = 08001

El problema es que el código se ejecuta correctamente durante bastante tiempo y de repente aparece esta excepción. Sin embargo, funciona correctamente cuando ejecuto el código de nuevo.

Podría alguien decirme qué podría estar mal y proporcionarme algunos consejos para resolver esto.

Fuente

2009-09-10 Anonymous

Consulte también este enlace http://www-01.ibm.com/support/docview.wss?uid=swg21962086 y http://www-01.ibm.com/support/docview.wss?uid = swg21600160 –

Parece que su conexión se está agotando. Aunque no estoy realmente donde está el problema. Puede ser con la conexión a su servidor db. Lamento no poder ayudarte más, pero espero que esto ayude.

Fuente

2010-03-16 17:31:20

Esto es un signo de no cerrar/liberar correctamente los recursos JDBC. Debe adquirir y para cerrar todos los recursos JDBC en el ámbito más corto posible, es decir, debe cerrarlos en orden inverso en el bloque finally del bloque try del mismo bloque de método que los haya adquirido. P.ej.

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) {} 
}

Si no cierra de manera adecuada tan pronto como sea posible, el PP va a tomar en propias manos antes o después y su aplicación puede romper tarde o temprano, ya que se ha encontrado a sí mismo.

Para mejorar el rendimiento de la conexión, utilice un grupo de conexiones. Sin embargo, ¡todavía tiene que adquirirlas y cerrarlas de la misma manera que aquí arriba! Ahora es solo la implementación de la agrupación de conexiones la que se preocupa por en realidad cerrando la conexión o no.

Fuente

2010-03-16 18:28:11 BalusC

Esperemos que el bloque try-with-resources en Java 7 ayude a aliviar algo de esto en el futuro. Aunque hay una parte de mí que se enfada con el temor de permitir que los desarrolladores se salgan con la suya sin limpiar los recursos. Me temo que podría llevar a un desarrollo descuidado. Y luego, ¿qué sucede si esos desarrolladores tienen que trabajar en el código pre-JRE 7? Solo pensando en voz alta en respuesta a tu respuesta. Pero definitivamente ++ en la respuesta. –

@Chris: definitivamente ARM ayudará mucho a reducir la repetición 'close()' -in-'finally'. Sin embargo, también puede optar por JPA, que a su vez reduce el texto completo de JDBC a un oneliner. – BalusC

Interesante. ¿Conoce algún artículo sobre JPA versus JDBC puro?Supongo que provengo de una experiencia en la que capas de abstracción a veces han empeorado y dificultado la depuración de nuestra aplicación. Encontré que JDBC puro es bastante simple (al menos cuando se trabaja solo con cadenas de SQL puro). Puedo ver dónde funcionaría mejor con Objects. ¿Y maneja el cierre del recurso para usted? –

Me parece que esto puede ser causado por https://www-304.ibm.com/support/docview.wss?uid=swg1IC63952

Al menos para nosotros es.

Revise su db2diag.log por mensajes de error ZRC=0x8005006D=-2147155859=SQLE_CA_BUILT "SQLCA has been built and saved in component specific control block." cuando recibe tales desconexiones.

A finales de esta semana tenemos la intención de actualizar a DB2 9.7 FixPack 3a - se escribirá de nuevo si eso ayudó.

Fuente

2011-03-14 16:14:05 Maxym

También recientemente nos enfrentamos a este problema, y fue debido a confusas cláusulas AND OR junto con una cláusula rownum <. Poner llaves en los lugares correctos lo resolvió.

Fuente

2011-09-13 13:24:01 ManojM

este post shud sea un comentario, no una respuesta – Chani

Respuesta

Cuestiones relacionadas