Мы получаем сообщение CommunicationException (от DBCP) после некоторого времени (несколько часов). Сообщение об ошибке (в Exception) находится в конце этого вопроса, но я не вижу wait_timeout, определенного в любом из файлов конфигурации. (Где мы должны смотреть? Где-то из каталога tomcat/conf?).Конфигурация Tomcat с использованием DBCP
Во-вторых, как было предложено Исключением, где можно установить свойство «Connector/J connection» autoReconnect = true? Вот определение ресурса в файле Conf/context.xml в котом настройки:
<Resource name="jdbc/TomcatResourceName" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true"
username="xxxx" password="yyyy"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://127.0.0.1:3306/dbname?autoReconnect=true"/>
В-третьих, почему JVM ждать до вызова ExecuteQuery() бросить исключение? Если время соединения завершено, метод getConnection должен выбросить исключение, не так ли? Это раздел исходного кода я говорю:
try {
conn = getConnection (true);
stmt = conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
rset = stmt.executeQuery (bQuery);
while (rset.next()) {
....
Наконец, здесь 1-й несколько строк трассировки стека ...
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 84,160,724 milliseconds ago. The last packet sent successfully to the server was 84,160,848 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection 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:406)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1074)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3291)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1938)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2107)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2642)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2571)
at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1451)
at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
Таковы причины, некоторые из нас думая «забыть dbcp, он может быть настолько зависим от конфигураций IDE и магии под капотом, что DriverManager.getConnection (...) может быть более надежным». Любые комментарии по этому поводу? Благодарим за понимание, MS
Если я правильно понимаю, DBCP поддерживает свое соединение в своем пуле, но сервер mySql истекает, поэтому, когда это соединение отправляется в приложение, это закрытое соединение. Имеет смысл, но это мое правильное понимание? Другой вопрос: Есть ли смысл использовать validationQuery/testOnBorrow, как вы упомянули, а также testWhileIdle и autoRecon ... в файле context.xml? Они идут в этот файл, не так ли? –
1. Ваше понимание верное. Все указанные мной решения дополняют друг друга. Устанавливая один, не мешает устанавливать другие. Луч и брекеты лучше ;-) Я бы выполнил все 3 решения. тестирование в режиме ожидания означает меньшее время ожидания в режиме «заимствования». Параметры свойств уменьшат неподходящие отключения. Да, все они входят в часть ресурса вашего контекста context.xml вашего webapp (позже развернутого tomcat в $ CATALINA_HOME/conf/Catalina/localhost/yourwebapp.xml). –
autoReconnect не рекомендуется - http://dev.mysql.com/doc/refman/5.0/ru/connector-j-reference-configuration-properties.html – OrangeDog