Господа знающие, объясните пожалуйста. Имеем вот такой сервлет
public class test {
/// Переменные класса
OracleDataSource datasrc = null;


public void init() throws ServletException {
// Получение JNDI - ресурса
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
datasrc = (OracleDataSource) envCtx.lookup ("jdbc/kemreg");
}

public void service (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// Получаем сессию
conn = datasrc.getConnection();
conn.setAutoCommit(false);
// Вставляем параметры в БД и выполняем кое-каие действия
.... insert into table ..... 1 (операция 1)
// На основе сделанные манипуляции вытаскиваем запрос
...
select * from table (операция 2)
// И выбранные селектом данные используем, ну к примеру для формировании HTML таблички ...
// Ну и закрываем сессию и возвращаем его в пул
conn.close()
}

Вопрос, как Вы уже заметили операции DML-ные но разные по типу insert-ы и select-ы. Поэтому завернуть их в один батч-пакет не получиться. Как можно достичь такого чтобы при многопотоковом доступе к сервлету, всегда выполнялась последовательность
--- Первый поток
{ В одной сессии с БД
(операция 1)
(операция 2)
}
--- Второй поток
{ В одной сессии с БД
(операция 1)
(операция 2)
}


А не так:
(операция 1) -- первого потока
(операция 1) -- втрого потока
(операция 2) -- пераовго потока
или
(операция 1) -- одна сессия
(операция 2) -- другая сессия

Использую редакцию сервлетов 2.3, ну расширение SingleThreadModel с депрекэйтино. Остается тольок завернуть операцию 1 и 2 блоком synchronized или вообще метод service c опцией synchronized.

Но все хорошо, тогда выскакивает момент, опеарция1 и операция 2 выполняется 2-10 секунд. Соотвествено при выполнения 10 запросов будем ждать от 2 до 100 секунд, так как synchronized
предпологает последовательную работу, как бы добиться параллельности ... Чтобы соблюдалась последовательность операции в рамках одной сессии (добиться атомарности в транзакции с БД)

Заранее спасибо...

Вместо insert .... к примеру выполнение какой либо процедуры...
Задача вот в чем

Данные вставлятся во временную табличку temporary table ее данные видимы тольок (в пределах сессии) Она нужна для того чтобы на базе не сделать выборку

select ....
from tempoary_table tt,
table1 tt1,
where tt.code = tt1.code
......

Вот еще
У меня в базе куча view многие из них параметризованы контекстами
поэтому нужно в начале проинициализировать контекст, а потом можно сделать select из view
т.е.
операция 1
begin
-- установка контекстов
end
операция 2
select * from view


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

Дизайне немного попахивает из-за неявных связей между операциями. Но это мелочи. А ответ у меня все тот же. Надо подкрутить уровень изоляции у транзакций.


Что-то не понял, плохо что выполняется процедура а потом селект. Нормальная практика, даже очень нормальная.

Надо подкрутить уровень изоляции у транзакций. Куда рыть, надеюсь это не в сторону EJB, у меня все простенько томкат и все (аппликешенов нету)

А не выкладывать в хранилище для того чтобы позже их вычитать Почему Вы решили что я хочу что вставил то и читаю ... Манипуляции данными с бд я делаю в БД, он это хорошо делает, даже очень хорошо...
Множество отчетов не удается получить обойтись лишь параметризацией запроса, иногда оптимальней еще выполнить процедурные штуки которые в результате вываливают в темповую табличку данные, которые потом и будет отображаться ... Ладно это не тема разговора, мне главное что-то на тему "изолированость транзакции" без EJB

Причем здесь:- Транзакции это понятия в первую очередь БД , транзакция это поледовательная цепочка операции, направленные для достижения какой либо цели, если одна из операции глюкнула то возвращаемся в первоночальную точку (транзакция типа не выполнилась), ну а если все операции в норме, то транзакция считаеться выполненой и остаеться тольок отчитаться о целесообразности проведенных операции (коммит или роллбэк)... Это не много не в тему, а то сейчас пойдет диалог на тему "Транзакционные издержки" ....

Ну неужели все так грустно, ну госопда, подскажите чего нить по теме!!! Ну вернулся я с армии, тольок денбелизовался, отслужил в ПВО, а сейчас системка разработанная мной до армии хандрить начала... Все раньше работала на Jserv, а тут чуваки без меня на новую спецификацию servlet подняли ...

Наехали!!!

Раз...Два..Три:- не заметил я

Ладно, вроде разобрался (со своей проблемой) ...


Спасибо за комментарии, поехал на зимнюю рыбалку короче ...