В документации разрабатываемого Apache Tomcat 11.0.28 описаны исправления ошибок, из-за которых соединения с базой данных могли использоваться одновременно разными запросами или некорректно завершать транзакции. Сборка 11.0.28-dev датирована 9 ноября 2026 года; официальный стабильный выпуск версии 11.0.28 пока не объявлен.
JDBC-пул мог передавать одно соединение с базой данных двум запросам
В Apache Tomcat готовят исправление ошибки асинхронного получения соединений из встроенного Tomcat JDBC Pool. Этот компонент хранит готовые подключения к базе данных и выдаёт их приложению по мере необходимости. Благодаря повторному использованию соединений серверу не приходится каждый раз устанавливать новое подключение.
Проблема возникала в ситуации, когда приложение запрашивало соединение асинхронно, а операция отменялась почти одновременно с его выдачей. По описанию разработчиков, отмена могла вернуть физическое соединение в пул, хотя первый получатель уже начал им пользоваться. Затем то же соединение доставалось другому запросу. В результате два участка приложения могли работать с одной сессией базы данных одновременно, а один из них иногда получал уже закрытое соединение.
В коде для 11.0.28 предусмотрено однократное закрепление соединения: его получает либо ожидающий запрос, либо операция отмены. Это устраняет описанное пересечение при конкурентной работе. Исправления относятся к Tomcat JDBC Pool; приложения с другими реализациями пула, например HikariCP, используют собственную логику управления соединениями.
Проверка JDBC-соединения больше не должна подтверждать чужую транзакцию
Ещё одна ошибка касалась проверки работоспособности подключения. Когда приложение возвращало соединение с незавершённой транзакцией, встроенная проверка пула при определённых условиях могла вызвать commit и тем самым сохранить изменения, которые приложение само ещё не подтвердило.
В подготовленном исправлении такая проверка завершает открытую транзакцию через rollback. Если откат завершился ошибкой, соединение признаётся непригодным для дальнейшего использования. При этом явно настроенные параметры commitOnReturn и rollbackOnReturn обрабатываются до проверки соединения.
Разработчики исправили и отдельную проблему с этими двумя параметрами: раньше их действие могло игнорироваться, если defaultAutoCommit не был явно установлен в false. Теперь учитывается фактическое состояние транзакции возвращаемого подключения. Для приложений, которые выполняют несколько SQL-операций в пределах одной транзакции, это связано с сохранностью промежуточных изменений и изоляцией работы соседних запросов.
В JNDIRealm устраняют ошибки LDAP-подключений и поиска групп
Изменения затрагивают и JNDIRealm — механизм Apache Tomcat, который может проверять пользователей и их роли через LDAP-каталог. Такой способ авторизации встречается во внутренних корпоративных веб-приложениях с централизованными учётными записями.
При использовании StartTLS состояние защищённого соединения прежде хранилось на уровне всего JNDIRealm. Из-за этого закрытие одного соединения из пула могло завершить TLS-сеанс другого, ещё активного подключения. В разрабатываемой версии состояние TLS привязывают к каждому соединению отдельно.
Исправлена и гонка при выборе основного или резервного LDAP-сервера: теперь адрес выбирается для каждой попытки подключения, без общего изменяемого флага. В поиске вложенных групп применяется уже вычисленное значение roleBase, благодаря чему группы на нескольких уровнях вложенности должны определяться и при использовании подстановок в пути поиска.
Есть нюанс совместимости для нестандартных расширений: в JNDIRealm удалено защищённое поле connectionAttempt и изменена сигнатура метода getDirectoryContextEnvironment(). Код, наследующий эти внутренние элементы класса, может потребовать изменений после выхода релиза.
Для HTTP/2 исправляют обработку соединений и нагрузку на процессор
В списке подготовленных исправлений есть ситуация с повышенным потреблением процессорного времени: клиент частично закрывал соединение после переключения протокола, а приложение продолжало отправлять ответ. Сервер мог снова и снова проверять поток ввода, в котором уже достигнут конец данных. В исправленном механизме такое бесполезное ожидание прекращается.
Для HTTP/2 доработана обработка больших заголовков ответов, которые укладываются в допустимый размер кадра после сжатия HPACK, но раньше могли ошибочно отклоняться. Добавлено и отключение клиентов, отправляющих большое количество неожиданных кадров подтверждения настроек HTTP/2.
Эти пункты относятся к конкретным сценариям работы сетевых соединений. Официальный список изменений не содержит замеров общего ускорения Tomcat после их исправления.
Apache Tomcat 11.0.28 пока находится в разработке
На 10 ноября 2026 года официальный список выпущенных версий Apache Tomcat указывает 11.0.27 как последнюю стабильную сборку ветки 11.0.x. Документация ночной сборки от 9 ноября помечает 11.0.28 как in development.
Таким образом, описанные исправления уже перечислены разработчиками в предварительном changelog, но дата выхода готового релиза и его окончательный состав пока официально не подтверждены. Наиболее заметные изменения касаются границ JDBC-транзакций, исключения одновременного использования одного соединения и устойчивости LDAP-подключений.
