2009-09-10 12 views
7

ottengo la seguente eccezione a volte:Java JDBC: Reply.fill()

com.ibm.db2.jcc.b.gm: [JCC] [t4] [2030] [11211] [ 3.50.152] Si è verificato un errore di comunicazione durante le operazioni sul socket sottostante della connessione, sul flusso di input del socket, o sul flusso di output del socket. Posizione dell'errore: Reply.fill(). Messaggio: reset della connessione. ERRORCODE = -4499, SQLSTATE = 08001

Il problema è che, il codice viene eseguito con successo per un bel po 'di tempo e poi improvvisamente ottengo questa eccezione. Tuttavia viene eseguito perfrettamente quando eseguo di nuovo il codice.

Potrebbe qualcuno per favore mi dica che cosa potrebbe essere sbagliato e mi forniscono alcune indicazioni per risolvere questo.

+0

Fare riferimento anche a questo collegamento http://www-01.ibm.com/support/docview.wss?uid=swg21962086 e http://www-01.ibm.com/support/docview.wss?uid = swg21600160 –

risposta

0

Sembra che la connessione stia scadendo. Non sono davvero dove il problema è però. Potrebbe essere con la connessione al tuo server db. Mi dispiace non posso aiutarti di più, ma spero che questo aiuti.

3

Questo è un segno di chiusura/rilascio non corretto delle risorse JDBC. È necessario acquisire e chiudere tutte le risorse JDBC nel più breve ambito possibile, vale a dire che è necessario chiuderle nell'ordine inverso nel blocco finally del blocco di metodo identico allo try come sono state acquisite. Per esempio.

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

Se non si chiude in modo corretto al più presto possibile, il DB avrà nelle proprie mani prima o poi e la vostra applicazione potrebbe rompersi prima o poi, come hai incontrato te stesso.

Per migliorare il collegamento di prestazioni, fanno uso di un pool di connessioni --potete ancora bisogno di acquisire e chiudere nello stesso modo, come qui sopra però! Ora è solo l'implementazione del pool di connessioni che sotto i cofani preoccupa in realtà chiudendo la connessione o meno.

+1

Speriamo che il blocco try-with-resources in Java 7 aiuti ad alleviare alcuni di questi in futuro. Anche se c'è una parte di me che ha paura di permettere agli sviluppatori di cavarsela senza ripulire le risorse. Temo che potrebbe portare a uno sviluppo sciatto. E poi cosa succede se quegli sviluppatori devono lavorare sul codice pre-JRE 7? Sto solo pensando ad alta voce in risposta alla tua risposta. Ma sicuramente ++ sulla risposta. –

+1

@Chris: sicuramente ARM sarà di grande aiuto nella riduzione del boilerplate 'close()' -in-'finally'. Tuttavia, si potrebbe anche optare per JPA che a sua volta riduce l'intera caldaia JDBC a un oneliner. – BalusC

+1

Interessante. Sei a conoscenza di articoli su JPA vs JDBC puro.Immagino di venire dall'esperienza in cui gli strati di astrazione a volte hanno reso la nostra applicazione sempre più difficile da eseguire il debug. Ho trovato la pura JDBC piuttosto semplice (almeno quando si lavora con stringhe puramente SQL). Posso vedere dove funzionerebbe meglio con gli oggetti. E gestisce la chiusura delle risorse per te? –

0

mi sembra che questo può essere causato da https://www-304.ibm.com/support/docview.wss?uid=swg1IC63952

Almeno per noi è.

Controlla la tua db2diag.log per ZRC=0x8005006D=-2147155859=SQLE_CA_BUILT "SQLCA has been built and saved in component specific control block." messaggi di errore quando si ottiene tali disconnessioni.

Più tardi questa settimana abbiamo in programma di passare a DB2 9.7 FixPack 3a - scriverà indietro se questo ha aiutato.

1

anche di recente ci troviamo di fronte a questo problema, ed era dovuto alla confusione delle clausole AND OR insieme a una clausola. Mettere le parentesi nei punti giusti l'ha risolto.

+1

questo post è un commento, non una risposta – Chani