Помогите мне избежать тайм-аута соединения с JPA, Hibernate и MySQL

Я использую JPA (Hibernate в качестве провайдера), Glassfish и MySQL. В разработке все отлично работает, но когда я развертываю приложение на тестовом сервере и позволяю ему работать (в основном в режиме ожидания) на ночь, меня обычно встречают этим утром:

[#|2011-03-09T15:06:00.229+0000|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=23;_ThreadName=Thread-1;|ERROR [htt\
p-thread-pool-8080-(1)] (JDBCTransaction.java:91) - JDBC begin failed
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 41,936,868 milliseconds ago.  The last packet \
sent successfully to the server was 41,936,868 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expirin\
g and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connec\
tion property 'autoReconnect=true' to avoid this problem.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1118)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3321)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1940)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
        at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:4956)
        at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:87)
        at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1473)
        at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:60)

Я пробовал использовать следующее в моем persistence.xml , но это не помогло:

Итак, это конфигурация C3p0; вполне возможно, что мне не хватает той части, которая фактически говорит спящему режиму «эй, используйте c3p0».

Я собираюсь попробовать предложение, которое прямо здесь в сообщении об ошибке: добавить autoReconnect = true к моему URL-адресу JDBC, но на данный момент это действительно начинает ощущаться как развитие карго-культа. Я был бы признателен за некоторые рекомендации о том, как правильно решить эту проблему. Сложно отлаживать, потому что цикл тестирования фактически означает «запустить его на ночь, посмотреть, что произойдет утром».

Я, вероятно, должен упомянуть, как я на самом деле использую соединения в своем приложении. У меня есть собственный Фильтр сервлетов , который перехватывает все запросы. Он создает EntityManager, сохраняет его в ThreadLocal и закрывается фильтром в блоке catch / finally. Все мои сущности получают ссылку на EntityManager из ThreadLocal .

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

Изменить: вот решение TL; DR:

• используйте пул соединений вашего контейнера, если вы можете (спасибо, @partenon)
• , убедитесь, что ваш пул соединений использует проверку соединения (спасибо, @matt b)

В моем случае мне пришлось зайти в консоль Glassfish в разделе «Ресурсы / JDBC / Пулы подключений», вкладка «Дополнительно», а затем включить проверку подключения:

Это был действительно решающий шаг. Вы также, вероятно, захотите установить для параметра Validate At Most Once какое-нибудь разумное значение, например 100 секунд. Если вы используете C3P0 или аналогичный, убедитесь, что вы настроили idle_test_period и PrimaryTestQuery .

Что бы вы ни делали, важно проверить свои изменения, чтобы увидеть, имеют ли они желаемый эффект. Чтобы тайм-аут происходил быстрее в MySQL, вы можете временно установить для параметра wait_timeout значение, например 30 секунд, отредактировав my.cnf . Это было огромным подспорьем в отладке этой проблемы, поскольку позволило мне проверить изменения за секунды, а не часы.