Как правильно организовать работу с транзакциями в nodejs проекте?
Есть проект API сервисов на NodeJS и базой данных на Postgres. В нем используются модели по принципу действий: т.е. каждая модель отвечает за неделимую сущность. Но при работе получается что операции с базой данных (insert, update, delete) нужно оборачивать в БД транзакцию, причем по логике работы получается, что таких операций может быть несколько из разных моделей.
Пример
При изменении персональных данных в приложении используются 2 модели: модель пользователя и модель логирования действий пользователя. Модель пользователя изменяет сами данные, а модель логирования вносит соответствующую запись об изменениях. Соответственно это является единой транзакцией для БД, и если хоть одно из действий закончилось неудачей - то должна отмениться вся транзакция. Работа с транзакциями опирается на полную изоляцию транзакций друг от друга, т.е. никакого read commited или "грязного" чтения. При работе с базой данных в каждую модель добавляется объект db, который является ссылкой на pool. Для того, чтобы в БД правильно работали транзакции - то все действия должны происходить в рамках одного коннекта, выделенного из pool-а.
Примерное построение логики в роуте на примере Promise:
-> Проверить данные
then-> начать транзакцию
then-> отправить запрос в БД на изменение (модель пользователя)
then-> отправить запрос в БД на логирование действия (модель логирования)
catch-> отменить транзакцию, залогировать ошибку
then-> commit транзакции
then-> ...
Собственно провлема заключается в том, чтобы оставить pool работу моделей с базой данных, но правильно организовать работу с подключениями. Сервис представляет собой API сервис - соответственно в нем есть роуты и прочие атрибуты web-приложения. Первоначально предполагал при web-запросе инициализировать один коннект к БД, т.е. отказаться от pool реализации. И этот коннект тянуть на все модели через параметр в функции. Но это считаю неправильным и костыльным. Выносить require модуля в роут, и там уже решать, работаем в рамках pool или connect - тоже как то не особо блещет изяществом. Среди "лучших практик" тоже не нашел такого, хотя может мало искал или не там.
Простой