Потому что за время выполнения requests запись уже может находится в базе

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

Не знаю, представляется ли это возможным, поскольку время выполнения requests может быть совершенно разным для одного и того же запроса, это не подконтрольно нам, но в данный момент верхняя граница 60 sec

Тогда 100% надо коннект возвращать в пул

Хорошо, добавлю в планы, спасибо

Я не знаю, что у Вас там конкретно за процесс, как я могу ответить?

Суть совета с переподключением в том, что на первом этапе выбираются исходные данные из БД для request, а потом, уже в новом соединении, проверяется, находится ли БД всё в том же "состоянии", когда был нужен именно такой request, и, если да — результаты записываются; а если нет ("не повезло") — выбрасываются.
Это подход optimistic locking, в общем.

Кроме того, если у вас всё это время ещё какая-нибудь открытая транзакция висит, то это тоже надо переделывать

Транзакция выполняется в самом конце, после работы requests. В любом случае, уже знаю, что и как нужно для этого изменить

Да, я про то, что нельзя допускать такое:
1) Открыл транзакцию
2) Выполнил запрос
3) requests (timeout=60 sec)
3) Опять запрос
4) Применил/откатил транзакцию

Да, я это понимаю. Нужно использовать соединение тогда и только тогда, когда есть в этом необходимость

Немного оффтоп, но интересно, почему в штат не хотят брать DBA? Это много где и упорно декларируется. Базы повсюду, ценность данных растёт, но администраторов баз данных нет даже в компаниях с огромными оборотами, где БД, как говорят, mission critical. При этом на любой чих берут отдельного человека (видно по вакансиям). В мире ситуация обратная, а России складывается именно так, хорошо ещё что не везде. Лет 10 назад DBA были востребованы, сейчас в районе статистической погрешности. Почему это происходит, как думаете?

nosql победил

не везде же NoSQL, но и туда DBA берут, даже у нас, особенно после потерь данных

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

в случае open source РСУБД - postgres/mysql ситуация аналогичная. тут не в nosql вопрос, думаю

Интересно, DevOps действительно этим занимаются? Судя по требованиям, они разбираются во всём, но понемногу. Где-то поглубже, а где-то поверхностно

"почему в штат не хотят брать DBA" - например, потому, что DBA прямо постоянно не требуются. Сужу чисто по своему опыту. У дизайнеров задачи постоянно есть, у разрабов - тоже, но с базой проблемы и сложность возникают не каждую неделю и даже не каждый месяц. Поэтому DBA в штат не берут (но это не значит, что к их услугам не прибегают периодически). Потому что большую часть времени они просто будут без задач (часть проблем могут решить штатные разрабы и девопсы).

Тут вообще ещё имеет место сам подход к разработке. Если всё на хранимках реализовано, то DBA, конечно, без задач сидеть не будет. Но везде, где я работал, бизнес-логика была в коде.

надо брать воинственного, чтобы ходил с палокой и бил разрабов за хреновые планы запросов!

Боевой DBA)