Почему Hibernate / JDBC / MySQL сбрасывает соединения через день или около того?

Question

У меня есть несколько серверных процессов, которые время от времени отвечают на сообщения от клиентов и выполняют транзакции только для чтения.

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

Когда я его проверил, оказалось, что спящий режим по умолчанию работает в каком-то режиме разработки, когда через несколько часов соединения сбрасываются, и я начал использовать c3po для пула соединений.

Однако даже при использовании c3po эта проблема возникает примерно через 24 часа после запуска серверов.

Кто-нибудь сталкивался с этой проблемой и знает, как ее решить? Я недостаточно знаком со сложностями настройки спящего режима.

Answer 1

Драйвер MySQL JDBC истекает через 8 часов бездействия и разрывает соединение.

Вы можете установить autoReconnect=true в своем URL JDBC, и это заставит драйвер переподключиться, если вы попытаетесь выполнить запрос после его отключения. Но это имеет побочные эффекты; например, состояние сеанса и транзакции не могут поддерживаться через новое соединение.

Если вы используете autoReconnect, соединение JDBC будет восстановлено, но оно автоматически не выполнит ваш запрос, получивший исключение. Поэтому вам нужно перехватить SQLException в вашем приложении и повторить запросы.

Подробнее см. http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configuration-properties.html.

Answer 2

MySql по умолчанию время ожидания по умолчанию в 8 часов .

Я получил то же исключение и решил проблему через 3 беспокойных дня. Проверьте, используете ли вы I hibernate3. В этой версии необходимо явно указать имя класса подключения. Также проверьте, находится ли банка в classpath. Проверьте шаги и комментарии в ссылке ниже

http://hibernatedb.blogspot.com/2009/05/automatic-reconnect-from-hibernate-to.html

Удалить autoReconnect=true

Answer 3

Я изменил свой файл конфигурации Hibernate, добавив эти строки, и теперь он работает:

    <property name="connection.autoReconnect">true</property>
    <property name="connection.autoReconnectForPools">true</property>
    <property name="connection.is-connection-validation-required">true</property>

Я думаю, что использование пула c3p0 лучше и лучше, но это решение пока работает и не представляет проблемы с муравьями.
Я включил Tomcat на 24 часа, и соединение не было потеряно.
Пожалуйста, попробуйте.

Answer 4

Я бы предположил, что практически при любой настройке клиент / сервер не рекомендуется оставлять соединения открытыми, когда они не нужны.

Я специально думаю о соединениях DB2 / z, но это в равной степени относится ко всем серверам (базе данных и т. Д.). Эти соединения потребляют ресурсы на сервере, которые лучше всего использовать в других местах.

Если бы вы держали соединения открытыми в корпоративной среде, где десятки тысяч клиентов подключаются к базе данных, вы, вероятно, даже поставили бы мэйнфрейм на колени.

Я за идею объединения пулов, но не за идею пытаться держать отдельные сессии открытыми навсегда.

Мой совет будет следующим:

1 / В вашем пуле соединений есть три вида соединений:

• закрыто (поэтому на самом деле не в вашем пуле).
• готово, то есть открыто, но не используется клиентом.
• активно, то есть используется клиентом.

2 / Пул соединений должен поддерживать небольшое количество готовых соединений, минимум N и максимум M. N можно настроить в зависимости от пиковой скорости, с которой ваши клиенты запрашивают соединения. Если количество готовых соединений когда-либо падает до нуля, вам нужно больше N.

3 / Когда клиент хочет установить соединение, дайте ему один из готовых (делает его активным), а затем сразу же откройте новый, если теперь готово меньше, чем N (но не заставляйте клиента ждать этого, чтобы завершить, или вы потеряете преимущество объединения). Это гарантирует, что всегда будет хотя бы N готовых соединений. Если никто не будет готов, когда клиент захочет, ему придется подождать, пока вы создадите новый.

4 / Когда клиент завершает работу с активным соединением, верните его в состояние готовности, если число подключений меньше M готово. В противном случае закройте его. Это предотвращает наличие более чем M подключений.

5 / Периодически перерабатывать готовые соединения для предотвращения устаревших соединений. Если подключений больше N, просто закройте самое старое соединение. В противном случае закройте его и снова откройте другой.

Преимущество этого состоит в том, что в вашем пуле соединений достаточно готовых И юношеских соединений без перегрузки сервера.