На Apache Tomcat конфигурацию источника данных можно включить в глобальный раздел файла server.xml . Вот, например, конфигурация для популярной базы данных MySQL:

Кроме того, следующие строки должны быть размещены в WEB-INF / web.xml для содержимого приложения.

Чтобы иметь возможность загрузить драйвер MySQL JDBC, вам необходимо включить библиотеку JAR в папку CATALINA_HOME / lib :

WildFly основан на предположении, что каждая библиотека сама является модулем. Итак, сначала мы превратим драйвер JDBC в модуль. Это можно сделать путем создания структуры пути к файлу в каталоге JBOSS_HOME / modules . Например, чтобы установить драйвер MySQL JDBC, создайте структуру каталогов следующим образом: JBOSS_HOME / modules / com / mysql / main .

1. Скопируйте JAR-файл драйвера JDBC в основной подкаталог.
2. В главном подкаталоге создайте файл module.xml, содержащий следующие определения (просто адаптируйте имя драйвера JDBC к вашему случаю):

Описанную выше процедуру можно также выполнить с помощью интерфейса командной строки , используя одну команду, которая создаст структуру файловой системы, скопирует драйвер JDBC в основную папку и настроит файл module.xml на основе параметров, предоставленных для CLI.

Вот как это сделать, если предположить, что драйвер JDBC MySQL доступен в папке / home / wildfly :

Теперь, когда ваш MySQL доступен как модуль на сервере приложений, мы зарегистрируем его как драйвер JDBC. При использовании CLI это одностадийная операция:

Теперь вы можете проверить, что ваш драйвер MySQL зарегестрирован через доступные драйверы JDBC. Вот как вы можете этого добиться:

Последний шаг фактически создаст источник данных, который будет использоваться вашими приложениями. Для этого мы будем использовать команду быстрого доступа к источнику данных CLI, которая требует в качестве ввода имя пула, привязки JNDI, параметры соединения JDBC и, наконец, параметры безопасности (имя пользователя и пароль):

Если вы выполнили вышеуказанные шаги, в вашем разделе источников данных должна быть доступна следующая конфигурация источника данных:

Настройка источника данных на сервере приложений — это первая веха для переноса ваших приложений на WildFly. Однако есть вероятность, что вы используете определенные параметры пула соединений, которые необходимо перенести на сервер приложений. Некоторые из этих параметров имеют одинаковое соответствие в WildFly, другие основаны на различных стратегиях объединения; поэтому вам необходимо адаптировать конфигурацию при переносе их на сервер приложений. Давайте посмотрим, как перенести наиболее распространенные параметры пула в WildFly:

Выбор правильного размера пула является обязательным для производительности ваших приложений. Минимальный размер пула Tomcat определяется параметром minIdle, а максимальный размер пула настраивается через maxActive . Начальный размер пула, с другой стороны, настраивается с параметром initialSize . Вот пример конфигурации:

При портировании на WildFly параметры называются соответственно min-pool-size и max-pool-size и могут быть установлены любым инструментом управления. Вот как их изменить для источника данных по умолчанию:

Начальный размер пула , с другой стороны, может быть установлен с помощью:

Дополнительно обратите внимание, что WildFly также имеет атрибут с именем pool-prefill , который определяет, следует ли пытаться предварительно заполнить пул соединений до минимального количества соединений:

Соединения, которые были созданы, но не использовались вашими приложениями, классифицируются как свободные соединения. У WildFly и Tomcat разные способы работы с простаивающими соединениями. Более подробно, Tomcat использует параметры minIdle и maxIdle для определения соответственно минимального и максимального числа незанятых соединений, которые должны храниться в пуле. Мы уже обсуждали параметр minIdle, который можно превратить в размер минимального пула WildFly. С другой стороны, параметр maxIdle не имеет соответствующего соответствия в WildFly. Самое близкое совпадение — это i dle-timeout-minutes , которое представляет собой количество минут, после которых неиспользуемые соединения закрываются (по умолчанию 15 минут). Вы можете изменить этот параметр, скажем, до 10 минут следующим образом:

Если все ваши подключения в пуле заняты, вашим приложениям, очевидно, придется ждать, пока соединение не будет освобождено. Как вы можете себе представить, для этого сценария существует тайм-аут, который обрабатывается параметром maxWait в Tomcat. В следующем примере время ожидания установлено на 30 секунд:

WildFly имеет соответствующий параметр с именем blocking-timeout-wait-millis ; в следующей команде CLI мы устанавливаем ее на 1 секунду (1000 мс):

Утечка соединения называется в терминах Tomcat « Прерванное соединение », которое происходит, когда вы создаете оператор, или PreparedStatement, или CallableStatement, и вы пропускаете закрытие соединения или оператора (или чаще вы не включаете соединение закрыть в, наконец, блок).

Вы можете обрабатывать оставленные соединения в Tomcat, включив параметр removeAbandoned . Если установлено значение true, соединение считается разорванным и может быть удалено, если оно не использовалось дольше, чем removeAbandonedTimeout (по умолчанию 300 секунд).

На стороне WildFly нет соответствующей настройки для внезапного закрытия соединений, которые квалифицируются как разорванные. С другой стороны, есть несколько полезных параметров, которые можно использовать для обнаружения или отслеживания проблемы.

Если вас интересуют операторы (и PreparedStatements), вы можете использовать параметр track-Statement, который проверяет наличие незамкнутых операторов, когда соединение возвращается в пул, и результирующие наборы закрываются, когда оператор закрывается / возвращается в подготовленный кэш операторов. Допустимые значения:

• false: не отслеживать заявления и результаты
• true: отслеживать операторы и наборы результатов и предупреждать, когда они не закрыты
• nowarn: отслеживать заявления, но не предупреждать о том, что они не разглашаются

Вот как установить этот параметр для использования NOWARN:

Кроме того, вы можете включить отладку уровня кэширования, который обрабатывается в WildFly управляемым соединением в кэше , частью подсистемы Connector (JCA).

Вам также следует включить параметр error , который позволит вам обнаружить любую ошибку, связанную с кэшированным диспетчером соединений:

Как только вы включите ведение журнала, вы увидите для каждого соединения, полученного из пула, следующую информацию:

С другой стороны, вы прочитаете следующее сообщение, когда соединения возвращаются в пул:

Если вы отлаживаете заявления, генерируемые вашими приложениями, вы можете легко узнать, где происходит утечка соединения.

Наконец, если вам нужны подробности о том, что происходит на уровне JDBC, вы можете записать в журнал операторы JDBC, установив в true свойство spy:

Чтобы отладить операторы JDBC в журналах вашего сервера, вам нужно создать элемент logger, который отслеживает пакет jboss.jdbc.spy. Вы можете сделать это следующим образом:

Перезагрузите конфигурацию сервера и проверьте журналы сервера, которые по умолчанию содержатся в JBOSS_HOME / standalone / log / server.log (автономный режим) или JBOSS_HOME / domain / [server-name] /log/server.log (режим домена).

Предварительно подготовленный оператор — это предварительно скомпилированный объект в базе данных, план доступа которого будет использоваться повторно для выполнения дальнейших запросов намного быстрее, чем обычные запросы. Подготовленные операторы могут также кэшироваться самим сервером приложений, когда необходимо выдавать одни и те же операторы для разных запросов. Возможности Tomcat jdbc-pool могут управлять кэшем подготовленных операторов с помощью перехватчика JDBC , который задается как свойство JDBC при создании пула. Например:

При работе в WildFly вы можете установить размер кэша PreparedStatement, написав атрибут prepare-reports -cache-size, как в следующем примере, который устанавливает его размер в 25 операторов: