ResultSet Объект закрыт - jtds

Question

Я использую JTDS для подключения к MS-SQL 2005. Я использую c3p0 в качестве пула соединений с БД, настроенного с помощью Spring.

Я случайно получаю SQLException: Invalid state, the ResultSet object is closed в скрипте Groovy, в котором я передал ссылку на пул соединений. Сценарий выполняется таймером очень часто. Под случайностью я подразумеваю, что сценарий работает идеально в 99% случаев, но когда он терпит неудачу, он делает это пару раз, а затем снова возвращается к правильной работе, выбирая, где он остановился. Вся критическая работа выполняется в транзакции, выполняющей очередь сообщений.

Логика ниже:

    //passed into the groovy context
    DataSource source = source;
    Connection conn = source.getConnection();

    ...
    //Have to omit proprietary DB stuff... sorry...
    PreparedStatement fooStatement = conn.prepareStatement("INSERT INTO foo (x,y,z) VALUES (?,?,?) select SCOPE_IDENTITY();");        
    ResultSet identRes = fooStatement.executeQuery();

    //This is where the execption is thrown.
    identRes.next();

    ...

    try{
         log.info("Returning SQL connection.");
         conn.close();
    }catch(Exception ex){}

Существует отдельный поток таймера, который запускает аналогичный скрипт groovy, в котором мы не видели этой проблемы. Этот скрипт использует аналогичные вызовы, чтобы получить соединение и закрыть его.

Первоначально мы думали, что второй сценарий мог захватывать одно и то же соединение из пула, сначала заканчивая, а затем закрывая соединение. Но документация c3p0 говорит, что вызов conn.close() следует просто вернуть его в бассейн.

Кто-нибудь еще видел это, или я что-то здесь упускаю?

Благодарю.

Answer 1

Мы решили это... C3P0 был настроен для отбрасывания соединений, которые были проверены дольше 30 секунд, мы сделали это, чтобы предотвратить тупиковую блокировку в базе данных (мы не контролируем настройку). Одна из транзакций выполнялась ужасно долго, и C3P0 сбрасывал соединение, что приводило к закрытой ошибке ResultSet. Удивительно, однако, что C3P0 не регистрировал инцидент, поэтому мы не увидели этого в журналах приложения.