Всем привет.

Нуждаюсь в советах.

В общем задача такая:

Есть очередь сообщений, получатель посредством Веб-сервисов (моего) дергает веб-метод (допустим getMessages) и получает эти сообщения.
После обработки их в своей системе он должен вызвать веб-метод (confirmMessages) подтверждения получения этих сообщений.

В getMessages я попросту делаю запрос в БД, например:




Далее id сообщений перегоняю в таблицу с каким-либо суррогатным GROUP_ID для группировки этих данных.
Этот GROUP_ID я возвращаю получателю. Commit;

В confirmMessages я ожидаю этот GROUP_ID и помечаю сообщения как отправленные.

Но это велосипед. Если вдумываться, то нужно будет решать кучу проблем, например таймауты подтверждения, повторное подтверждение, область видимости неподтвержденных данных в getMessages и т.д.

Может уже есть готовые решения (например в JavaEE) для решения этой задачи?
т.е. мне нужно какое-то подобие транзакций более высокого уровня чем EJB на уровне WS.

Спасибо!

Petro123EDUARD_2,
Тебе по ws прислали УдалитьПетрова и потом спрашивают подверждения или отката?

Мне присылают - "отдай мои сообщения", а потом присылают "подтверждаю, что забрал свои сообщения, не присылай мне их больше".

BlazkowiczВо-первых select for update можно выполнять только в том случае если у вас транзакция кратковременная (и речь не только о БД). В вашем случае это пуля в лоб системе.

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

Если я не буду лочить эти записи, то при вставке в таблицу для группировки эти данных - попадутся дубликаты, да и потребитель больше 1 раза их обработает.

Blazkowiczто, уверен, что есть решение получше

за этим я и пришел сюда =)

Petro123ID потребителя при запросе?

да

Petro123Самому ставить галку в бд.

А если связь между потребителем и веб-сервисом пропала? у него экзепшин транспортного уровня, а у меня фиксация транзакции?)

Leonid KudryavtsevА ты уверен, что сейчас они лочатся как задумано?

уверен, в запросе выборки сообщений из бд, есть условие not in\exists к этой самой групповой таблице.

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