buldozer01Да нет это реальная задача
У реальной задачи - реальная постановка. Здесь же ты её ещё не рассказал.

buldozer01 как и остальные линки которые ты не поленился поискать непонятно только зачем.
Да, столько труда приложил. Сначала в пофиль зайти, потом темы автора. Аж два клика. Чуть не надорвался.

buldozer01Я описал необходимое и достаточное количество условий задачи

Нет. Ты описал свое решение задачи.

buldozer01А зачем оно - на форум нет смысла писать.

Без сомнения.

buldozer01Нечего сказать дельного по теме - прошу не троллить.
Заметь, я тут единственный кто тебе пытается объяснить про XA ресурсы и почему работа внутри одной DB транзакции не может бы конкурентной и т.п. А ты как хамил так и продолжаешь.
И чем тебе предложеные решения не подходят, ты тоже себя не утруждаешь объяснить. Зато чего не по теме ляпнуть, так это в первую очередь.

забыл никТочнее возможно, но доступ к коннекшену все равно будет последовательный изо всех потоков, так смысл?
Я более чем уверен что в конечной системе к одному соединению будет именно такой последовательный доступ, просто из разных потоков. Но топикастеру нужно время чтобы это понять. Вот и никак не ответит ни на один комент в тему.

забыл никТочнее одна транзакция - один коннекшен - один тред
Не обязательно. Если используется асинхронный подход, то вполне можно перебросить конекшн в другой поток и асинхронно продолжить тразнакцию. Но автор же не хочет объяснить какая у него вокруг этой задачи архитектура.

buldozer01В принципе пока нас устроил вариант с блокировкой на каждом execute
Здесь как раз хорошо должна подойти оптимистичная блокировка, которую ты так хотел применить. Ведь по логике конкурентные запросы к одной транзакции должны быть исключены. Т.е. в большинстве случаев не происходить вообще.

buldozer01>>Вот и никак не ответит ни на один коммент в тему.
Ну Ну ...
Ну, вот опять.

buldozer01Идея складировать все sql запросы в очередь и потом их выполнять вот над чем я в серьез думаю
Но с локом оно синхронно и как то надежнее что ли
13551827
Я тебе эти два решения первым же коментом привел. Отказ от пессимистичных блокировок может серьезно увеличить производительность. Иначе у тебя вся асинхронность лесом пойдёт. Ты её обратно к синхронности приведешь за счет локов.
Чем лок "надежнее" - не понятно.

buldozer01Транзакция XA одна тредов много.

Я тебе уже выше писал. Не мешай в кучу глобальную транзакцию и транзакцию в базе. Но ты это успешно продолжаешь игнорировать.

buldozer01Обычно я по утрам пью чай а вот сегодня выпил кефиру ....
сорри конечно - но бывают и другие кейсы
Тебе дело пишут, а ты вы-бываешься.
Смотри. Продюсер открывает XA транзакцию. Отрывает DB Connection. Что-то туда пишет.
Отправляет асинхронное сообщение.
Консюмер получает сообщение - состояние он как раз должен получить из сообщения, а не из базы данных.
Обрабатывает его через свой DB Connection и вместе они дружно комитят XA транзакцию и оба DB соединения.

Разница в том что ты хочешь состояния вычитать через базу. Нафига? Когда его можно передать через очередь.
С другой стороны можно передать ссылку на Connection. И пусть себе читает. Тогда важно чтобы не использовались топики.