Я использую mybatis для подключения к оракулу.
Мой конфиг mybatis:
<settings>
<setting name="lazyLoadingEnabled" value="true" />
<setting name="aggressiveLazyLoading" value="false" />
<setting name="logImpl" value="${logImpl}" />
<setting name="defaultStatementTimeout" value="10" />
</settings>
<environments default="default">
<environment id="default">
<transactionManager type="JDBC" />
<dataSource type="POOLED">
<property name="driver" value="${jdbc.driver}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<property name="poolPingConnectionsNotUsedFor" value="290000"/>
<property name="poolPingQuery" value="SELECT COUNT(*) FROM RESORT"/>
<property name="poolPingEnabled" value="true"/>
</dataSource>
</environment>
</environments>
Мой код открытого сеанса похож на
SqlSession sqlSession = factory.openSession();
Object result = null;
try
{
QueryInfoMapper mapper = sqlSession.getMapper(QueryInfoMapper.class);
result = mapper.queryInfoFromOpera(mybatisMapping);
} finally
{
sqlSession.close();
}
Из-за того, что область действия приложения ограничена, и sqlSession не может использоваться в области приложения, поэтому мне приходится управлять sqlSession самостоятельно.
Журнал
2019-04-11 15: 30: 35,773 ИНФОРМАЦИЯ [стандартный вывод] (задание по умолчанию-60) Открытие соединения JDBC
2019-04-11 15: 30: 41 860 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-57) Плохое соединение. Не удалось откатиться
2019-04-11 15: 30: 41,861 INFO [стандартный вывод] (задание по умолчанию-57) Заявленное просроченное соединение 962608913.
2019-04-11 15: 30: 41,861 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-57) Из пула возвращено плохое соединение (962608913), получено другое соединение.
2019-04-11 15: 30: 41 895 INFO [stdout] (задание по умолчанию-57) Создано соединение 1812494479.
2019-04-11 15: 30: 41 895 ИНФОРМАЦИЯ [стандартный вывод] (задание по умолчанию-57) Установка для автоматической фиксации значения false при подключении к JDBC [oracle.jdbc.driver.T4CConnection@6c08788f]
2019-04-11 15: 30: 41 895 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-57) ==> Подготовка: ВЫБЕРИТЕ TRAVEL_AGENT_NAME FROM (ВЫБЕРИТЕ TRAVEL_AGENT_NAME ОТ OPERA.NAME_RESERVATION ГДЕ RESV_NAME_ID =?) ГДЕ ROWNUM = 1 * 1028 = 1
2019-04-11 15: 30: 41 896 ИНФОРМАЦИЯ [стандартный вывод] (задание по умолчанию-57) ==> Параметры: 288541 (строка)
2019-04-11 15: 30: 41 900 INFO [stdout] (задание по умолчанию-57) <== Столбцы: TRAVEL_AGENT_NAME </p>
2019-04-11 15: 30: 41 900 INFO [stdout] (задание по умолчанию-57) <== Строка: ноль </p>
2019-04-11 15: 30: 41 900 INFO [стандартный вывод] (задание по умолчанию-57) <== Итого: 1 </p>
2019-04-11 15: 30: 41,900 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-57) Сброс автоматической фиксации на true при подключении JDBC [oracle.jdbc.driver.T4CConnection@6c08788f]
2019-04-11 15: 30: 41 , 900 INFO [стандартный вывод] (задание по умолчанию-57) Закрытие соединения JDBC [oracle.jdbc.driver.T4CConnection@6c08788f ]
2019-04-11 15: 31: 00 , 788 INFO [стандартный вывод] (задание по умолчанию-60) Плохое соединение. Не удалось откатиться
2019-04-11 15: 31: 00,788 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-60) Заявленное просроченное соединение 1228464923.
2019-04-11 15: 31: 00,788 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-60) Из пула возвращено плохое соединение (1228464923), получено другое соединение.
2019-04-11 15: 31: 00,820 INFO [стандартный вывод] (задание по умолчанию-60) Создано соединение 265625885.
2019-04-11 15: 31: 00,820 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-60) Установка для автоматической фиксации значения false при подключении JDBC [oracle.jdbc.driver.T4CConnection@fd5211d]
2019-04-11 15: 31: 00,820 INFO [стандартный вывод] (задание по умолчанию-57) Возвращено соединение 1812494479 в пул.
При просмотре журнала, согласно отметке времени, это происходит при закрытии соединения (здесь это транзакция)
Но чтобы его закрыть, нужны 9 или 19 секунд. Второй журнал «Плохое соединение. Невозможно выполнить откат». Я не могу найти, где на самом деле причина. И какой метод занимает столько времени. Эта проблема возникает не каждый раз, а случайно.
Я думал установить <property name="poolMaximumActiveConnections" value="40" />, чтобы увеличить количество соединений. Я не уверен, поможет ли это.
В чем причина сбоя соединения / транзакции? Как избежать неудачного закрытия соединения / транзакции?
===========================
Обновление: я столкнулся с этой проблемой снова, и журнал идет что-то другое:
2019-04-13 15: 42: 31 812 INFO [стандартный вывод] (задание по умолчанию-86) Открытие соединения JDBC
2019-04-13 15: 42: 35,493 INFO [stdout] (задание по умолчанию-62) Сбой при выполнении запроса ping «SELECT COUNT (*) FROM RESORT»: ошибка ввода-вывода: истекло время ожидания чтения сокета
2019-04-13 15: 42: 35,493 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-62) Соединение 1963609369: ПЛОХО: ошибка ввода-вывода: истекло время ожидания чтения сокета
2019-04-13 15: 42: 35,493 INFO [stdout] (задание по умолчанию-62) Из пула было возвращено плохое соединение (1963609369), получено другое соединение.
2019-04-13 15: 42: 35,493 INFO [stdout] (задание по умолчанию-62) Проверено соединение 195963529 из пула.
2019-04-13 15: 42: 35,493 INFO [стандартный вывод] (задание по умолчанию-62) Тестирование соединения 195963529 ...
2019-04-13 15: 42: 54,448 INFO [stdout] (задание по умолчанию-62) Ошибка выполнения запроса ping «SELECT COUNT (*) FROM RESORT»: ошибка ввода-вывода: истекло время ожидания чтения сокета
2019-04-13 15: 42: 54,448 INFO [стандартный вывод] (задание по умолчанию-62) Соединение 195963529 ПЛОХОЕ: ошибка ввода-вывода: истекло время ожидания чтения сокета
2019-04-13 15: 42: 54,448 ИНФОРМАЦИЯ [stdout] (задание по умолчанию-62) Из пула возвращено плохое соединение (195963529), получено другое соединение.
2019-04-13 15: 42: 54 479 INFO [стандартный вывод] (задание по умолчанию-62) Создано соединение 741137137.
Кстати, я поменяю ping sql на SELECT 1 FROM DUAL.
Что могло вызвать тайм-аут чтения этого сокета?