JDBC по природе своей не многопоточный. Поэтому вариантов всего два. Либо синхронизировать все потоки по одному локу.
Либо складывать все задачи в очередь и разгребать одним потоком для запуска SQL.
Если есть какая-то конкретика про используемые SQL, то можно ещё что-то придумать. Например не использовать ResultSet с открытым курсором, а вычитывать данные в CachedRowSet и сразу же освобождать Connection.

buldozer01А можно в каждом новом треде создавать новый тред и между коннекшенами пробрасывать уровень изоляции такой чтоб были выидны не закомиченные изменения другого конекшена ?
Может проще версии использовать?

buldozer01Версии чего ?
Версии записей в базе хранить и использовать.

buldozer01А можно в каждом новом треде создавать новый тред и между коннекшенами пробрасывать уровень изоляции такой чтоб были выидны не закомиченные изменения другого конекшена ?
Может всем Dirty Read разрешить и всё. 8)))

buldozer01А можно в каждом новом треде создавать новый тред и между коннекшенами пробрасывать уровень изоляции такой чтоб были выидны не закомиченные изменения другого конекшена ?
Объясни лучше почему Connection только один. 8)

Basil A. SidorovСейчас вы пытаетесь достать левое ухо, вывернув правую руку за спину - утомительно и вредно.
Заметь, это нужно сделать "грамотно".

buldozer01Транзакция одна

Вооот ключевой момент.
Т.е. много потоков шарят одну транзакцию и ты предполагаешь что RDBMS должна реализовывать конкурентный доступ к данным внутри одной транзакции? Эдак весь ACID на хрен сведётся.

buldozer01Транзакция одна
если можно сделать такое многими конекшенами почему бы и нет
Можно. Но обращения всё равно придётся сериализовать (выстраивать в очередь). Достаточно странно, если одна транзакция понадобиться параллельным потокам. Скорее всего в системе одновременно транзакцию будет использовать один поток.
Ваш же движок будет перебрасывать connection между потоками. Но одновременно с ним будет работать только один. Поэтому достаточно себя обезопасить через lock или очередь.

buldozer01 http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_xa.htm#BABBDDFC
Вот интересный тынц в тему
Да, пожалуйста. Только заметь что там подразумевается работа с многими XA ресурсами. У тебя один XA ресурс. Конкурентный доступ к нему в одной транзакции никто не обещал.
И вообще не стоит путать глобальную XA транзакцию и локальную транзакцию отдельного ресурса (DB Connection).

забыл никА потом окажется что "это был теоретический вопрос(с)". Я даже и придумать то не могу зачем такая шляпа может понадобиться.
Зришь в корень
http://www.sql.ru/forum/actualsearch.aspx?a=buldozer01&ma=0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

buldozer01На прикладном уровне юзера делает

int t = execute ("select t from t");

После execute я уснуть должен ? и дождаться пока результат в очереди вычислится ?
Мля, ну нужно синхронно - уснул. Нужно асинхронно - подписался на ответ и освободил поток.

забыл никА разве коннекшен Serializable? Нету IDE под рукой чтобы проверить.
нет, конечно. Но не всякая очередь это JMS, где обязательно персистить нужно. При особом желании локально можно и передать.