💡 Почему приложение теряет соединение с базой данных? Разбираем на примере реальной ошибки

🔍 Ситуация:
Приложение работает, но через какое-то время начинаются странности: база данных внезапно "отказывает", в логах ошибки
JDBCConnectionException - Unable to acquire JDBC Connection
и если присмотреться - рядом еще
SocketException - Too many open files.

О каких files речь и почему это мешает подключению к БД?
Вы проверяете PostgreSQL — соединений немного (ну вдруг "too many" как-то относится к соединениям), всё в порядке. В чём же проблема?

🕵️ Ответ скрыт на уровне операционной системы:
Ошибка Too many open files говорит о том, что приложение исчерпало лимит файловых дескрипторов. Linux (на сервере с вашим приложением) выделяет каждому процессу ограниченное количество дескрипторов, которые используются не только для работы с файлами, но и для сетевых соединений (сокетов)!

Если в приложении какие-то ресурсы (например, сокеты или файлы) открываются, но не закрываются, дескрипторы "утекают". В итоге, когда приложение пытается установить новое соединение с базой данных, система просто не может выделить дескриптор для нового сокета.

⚙️ Причина оказывается не в базе, а в куче "забытых" файлов или других ресурсов.

🔧 Как избежать?
Проблема решается дисциплиной работы с ресурсами. Можно использовать автоматические механизмы языка, такие как try-with-resources, или следить за ручным закрытием.

🛠 Вывод:
Ошибка соединения с базой данных и лимит открытых файлов на первый взгляд не связаны, но на практике это замкнутая цепь. Утечки файлов → превышение лимита дескрипторов → невозможность создать сокет → сбой подключения к БД.

В следующих постах расскажем как ручками проверить количество активных, ожидающих и зависших подключений к БД.

💡 Совет: как ускорить отладку

В процессе дебага нужно проверить небольшое изменение в методе, но перезапускать всё приложение ради одной строки кода — слишком долго? Используйте механизм HotSwap для быстрого внесения изменений:

1️⃣ Запускаете Debug Mode.
2️⃣ Делаете изменения в коде.
3️⃣ Заходите в меню Build - пункт Recompile 'ChangedClass.java' (или просто Ctrl+Shift+F9), в окошке жмёте Reload -> видите сообщение о том, что один класс reloaded.
4️⃣ Как ни в чем не бывало продолжаете дебажить код, но уже с изменениями.

⚠️ Ограничения:
Работает только для изменений в методах (без добавления новых полей/методов/классов).
Более сложные изменения могут потребовать использования инструментов, таких как JRebel.

🚀 Итог: вместо долгого перезапуска вы сразу видите результат изменений в работе приложения. Попробуйте — это действительно экономит время!
P.S. Речь про Idea, конечно же

✨Иногда в пылу разработки мы забиваем забываем об одной важной детали при работе с реляционными БД — индексах на внешних ключах

🔍Казалось бы, мелочь: зачем заморачиваться с ещё одним индексом, если сам внешний ключ уже прописан? Но именно индекс по FK способен ускорить join-запросы (а также каскадное удаление), особенно при работе с большими объёмами данных. Еще и общая нагрузка на систему снижается. В результате вы получаете более отзывчивое приложение и довольных пользователей

✅Если у вас в базе есть внешние ключи (а они есть), убедитесь, что к ним привязаны соответствующие индексы — и ваша СУБД скажет вам спасибо

upd
в комментах вскрылось, что по этому поводу говорит оф.документация по постгресу ⬇️

SERIAL vs GENERATED AS IDENTITY в PostgreSQL - что выбрать

В большинстве случаев id наших таблиц - это число с автоинкрементом. И под это определение идеально подходит тип SERIAL (или BIGSERIAL) - при его использовании для колонки задается тип INT (или BIGINT, аналог лонга в джаве) + последовательность с такими параметрами как начальное значение, текущее, шаг инкремента и т.д.

Но это вариант считается устаревшим.
Начиная с версии PostgreSQL 10 (т.е. довольно давно) появился более современный и гибкий способ — GENERATED [ALWAYS | BY DEFAULT] AS IDENTITY. В чём же разница?

🪗

CREATE TABLE some_entity (
    id SERIAL PRIMARY KEY,
    -- other columns
);

- Под капотом создаёт отдельную SEQUENCE и использует nextval() для автоинкремента
- Не соответствует стандарту SQL и имеет ограничения в управлении последовательностью
- Всё ещё встречается в старых проектах
- ПОЗВОЛЯЕТ вставлять значения идентификатора принудительно!

🚀

CREATE TABLE some_entity (
    id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    -- other columns
);

- Полностью соответствует SQL:2003
- Интегрированная логика без необходимости управлять отдельной SEQUENCE
- Легко изменять параметры автоинкремента с помощью ALTER TABLE
- ЗАПРЕЩАЕТ вставлять значения идентификатора принудительно!

Чуть подробнее про п.4:
При использовании SERIAL/BIGSERIAL можно в команде UPDATE указать поле id и соответствующее значение в VALUES, и оно будет добавлено в новой строке. Но что если инкремент сиквенса потом дойдёт до этого значения (допустим, сейчас сиквенс на 100, мы вставили 200)? Он же его обойдёт? Обойдёт же?
А ничего подобного. Сиквенс на это не посмотрит, выдаст очередное значение, и операция завершится ошибкой (что-то типа "значение id = n нарушает ограничение первичного ключа").
Конечно, в стандартном сценарии работы с таблицей, тем более с помощью JPA, это не критично, но всё же.
При использовании GENERATED ... AS IDENTITY тоже можно вставлять свои значения в id, но только если ALWAYS заменить на BY DEFAULT (но тогда и нюанс с нарушением ограничения не исчезает).
Если же написать ALWAYS, то принудительная вставка своих id будет невозможна.

Кстати, пишите в комментах свои предположения - для чего может быть нужно вставлять свои id и как всё-таки избежать конфликта (чтобы сиквенс не напоролся на вставленное значение🤔🤔🤔)?

И немного про управление последовательностью (сиквенсом):
Её можно сбросить на единицу или начать с другого значения несколькими способами

напрямую изменить сиквенс

ALTER SEQUENCE some_entity_id_seq RESTART WITH 1;

или, если используется GENERATED...IDENTITY - сделать это через alter таблицы

ALTER TABLE some_entity ALTER COLUMN id RESTART WITH 1;

или, например, с подзапросом для продолжения с максимального значения на данный момент

SELECT setval('some_entity_id_seq', (SELECT MAX(id) FROM some_entity));

Итог:
всё тлен, делайте какие угодно id, хоть прямо в джаве генерируйте, кому какое дело