давайте я еще повбрасываю

создавать какой-то там контекст к базе отдельно на каждый http-запрос - хуита, которая к тому же разваливается, стоит сделать шаг в другой тред
транзакционные запросы - как правило хуита, в 99% случаев достаточно запросов по айдишнику и оптимистичной блокировки
держать стейт сущностей, чтобы потом из этого найти измененные, чтобы из них создать запросы, чтобы потом их отправить одной пачкой - тоже хуита, хотя если очень нужны транзакции, то можно, конечно. но в этом случае вместо классического подхода в движок должен просто скармливаться какой-то Action, который вращается там до тех пор, пока не выиграет транзакцию или не исчерпается лимит повторов

это самый простой способо рельизации без гемора)

ксли недо что-то отдельно оптимизровать, то да

Тут согласен

самый простой - это await ORM.persist(entity)

в спринге там та-же тема только под капотом

EntityManager типо синглтон, но под капотом он использует ThreadLocalStorage для меджинга конекшенов

> в спринге

именно поэтому-то я всю эту хуйню и ненавижу

Но у нас есть кейс. Транзакция через примерно 10 - 20 записей/запросов идет

😇

в смысле "через" ?

я пока толком не добрался до ASP.NET, но уже отсюда могу сказать, что такой поебени как в спринге там явно нет

типо разные ХТТП запросы? и где-то ждет в фоне тарнзакция?

попахиваает ораклом

Транзакция в течении запрософ/записей

ну ХТТП запрос один на транзакцию? если да, то норм

Да один

Но внутри много логики.

ну в принципе это нормально

Там важна консистентность во время всего запроса

Еще вброшу: в большинстве случаев надо не транзакции катать, а кидать в очередь команду на выполнение, типа "добавить комментарий с текстом Х как ответ к комментарию Ъ". А оно там в бэкграунде пусть разбирает. Заодно и запросы на чтение можно дедуплицировать.