Набор результатов JDBC закрыть

Я занимаюсь профилированием своего Java-приложения и нашел интересную статистику для вызова jdbc PreparedStatement:

Ниже приведены сведения о среде: База данных: Sybase SQL Anywhere 10.0.1 Драйвер: com.sybase.jdbc3.jdbc. Пул подключений SybDriver: c3p0 JRE: 1.6.0_05

Рассматриваемый код приведен ниже:

try {
    ps = conn.prepareStatement(sql);
    ps.setDouble(...);
    rs = ps.executeQuery();
              ......

    return xyz;
}
finally {
    try {
        if (rs != null) rs.close();
        if (ps != null) ps.close();
    }
    catch (SQLException sqlEx) {

    }
}

Из статистики JProfiler я обнаружил, что только этот конкретный оператор resultspace.close () занимает много времени. Он варьируется от 25 мс до 320 с, в то время как для других кодовых блоков, которые имеют идентичную природу, я обнаружил, что это занимает около 20 микросекунд.

На всякий случай я провел этот тест производительности несколько раз и подтвердил эти данные. Меня озадачивает такое поведение - Мысли?


java performance jdbc c3p0
person KM.    schedule 23.03.2010    source источник
comment
Какой тип SQL вы выполняете: INSERT / UPDATE / SELECT / вызов хранимой процедуры? Есть ли автокоммит? Вы писали о другом быстродействующем блоке кода: он отличается только в SQL или есть другое отличие?   -  person Michał Niklas    schedule 24.03.2010
comment
Один комментарий к вашему коду: вы должны вызывать методы close () в отдельных блоках try, иначе ps.close () не обязательно будет вызываться, и вы даже не заметите, поскольку нет обработки потенциального исключения.   -  person the-banana-king    schedule 24.03.2010
comment
@Michal: SQL - это простой оператор выбора. @ the-banana-king: хорошее замечание. - мы находимся в процессе рефакторинга кода для Spring jdbc, поэтому я надеюсь, что это позаботится об этом.   -  person KM.    schedule 24.03.2010
comment
320 секунд? 320 секунд может быть таймаутом DNS? TCP / IP не успеет жить (TTL) выше 255 с.   -  person Tom Hawtin - tackline    schedule 24.03.2010
comment
Вы полностью используете набор результатов во всех случаях (то есть вызовите rs.next (), пока он больше ничего не вернет)?   -  person Yishai    schedule 24.03.2010

Ответы (4)


arrow_upward
3
arrow_downward

Эта производительность зависит от драйвера JDBC. Пул соединений C3P0 не должен на него влиять. Я бы посоветовал повторно протестировать его с более новым или другим драйвером JDBC. Альтернативой драйверу Sybase является драйвер jTDS. Я не уверен, как это работает по сравнению с драйвером Sybase, но известно, что он очень эффективен по сравнению с собственным драйвером MSSQL JDBC Microsoft.

Независимо от реальной проблемы, вы должны фактически вызывать close() методы, каждый в своем собственном try блоке, иначе нет гарантии, что они будут все закрыты. Если при первом закрытии выбрасывается SQLException, последующие вызовы закрытия выполняться не будут. Apache Commons DbUtils может помочь принять шаблонный код прочь.

person BalusC    schedule 23.03.2010
comment
Спасибо за подсказку - попробую с новым драйвером. Что касается комментария к коду, у нас запланированы истории разработки, в которых мы будем переносить этот код на Spring JDBC. - person KM.; 24.03.2010
comment
Несколько блоков try также позволят вам избавиться от null беспорядка. - person Tom Hawtin - tackline; 24.03.2010
comment
Нет, я бы не согласился с Томом Хотином и рекомендовал закрыть статические методы. Оберните эти операторы close в отдельные блоки try / catch и обязательно проверьте значение null. Или просто используйте Spring JDBC. Они написали это лучше, чем вы. - person duffymo; 24.03.2010

arrow_upward
1
arrow_downward

Что касается частично связанной заметки, ознакомьтесь с Apache Commons DbUtils и Dbutils.closeQuietly () метод для простого управления закрытием соединений / операторов / наборов результатов в правильном порядке с правильной обработкой исключений.

person Brian Agnew    schedule 23.03.2010

arrow_upward
0
arrow_downward

Действительно ли вызов метода вызывает загрузку процессора во время задержки или просто ждет? Закрытие ResultSet, скорее всего, связано с удаленным обменом данными с базой данных, и я предполагаю, что в некоторых обстоятельствах это может занять некоторое время.

person jarnbjo    schedule 23.03.2010
comment
Хм - База данных находится в удаленном месте в другой географии. Тем не менее, в кодовой базе есть множество таких подготовленных заявлений, которые, кажется, выполняются нормально - кажется, только этот конкретный блок кода имеет проблему. - person KM.; 24.03.2010

arrow_upward
0
arrow_downward

Если оператор является выбранным и вы не потребляете все данные, попробуйте отменить оператор перед его закрытием.

person Winder    schedule 24.03.2010