Менеджер транзакций

http://static.springsource.org/spring/docs/2.0.8/reference/transaction.html
оно?

Только версию не 2.0

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

> то непонятно как они умудряются работать с одной базой данных.

а чего непонятного-то? Стандартная ситуация: есть БД с информациях о заказах и N магазинов, которые любые свои операции сохраняют в этой БД. При этом не то что инстансы разные, сами приложения могут быть в корне разными.

//решения кроме «написать самому» не знаю :(

решения кроме «написать самому» не знаю

JTA?

Стандартная ситуация: есть БД с информациях о заказах и N магазинов, которые любые свои операции сохраняют в этой БД

Да, но как получается, что для выполнения операции нужно делать распределенные запросы в несколько приложений? База одна, грех не сделать операцию, которая делает все, что нужно в одном приложении. Тут типичнейшее ССЗБ получается. И никакие менеджеры транзакций не нужны. Которые, кстати говоря - УГ.

Я еще понимаю, когда несколько приложений, несколько БД, да. Да и тут на идемпотентных операциях и undo логах можно выкрутится без всяких распределенных транзакций.

> Ты не написал одинаковые ли инстансы приложений крутятся на аппсерверах. Если одинаковые, то менеджер транзакций не нужен.

Инстансы приложений одинаковые. При этом заранее неизвестно, какой пользователь будет обслуживаться каким сервером.

Может быть, придумать какую-нибудь шину сообщений, к которой будут подключаться серверы приложений?

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

Наверное переделывать поздно. Но обычно лочить ничего не нужно. Используешь поле для версионирования и все.

Вот это странно:

то все другие инстансы приложения должны оповестить пользователей об этой операции

А у тебя стейтовое приложение что ли?

Может быть, придумать какую-нибудь шину сообщений, к которой будут подключаться серверы приложений?

Я так до конца не понял задачу, но в качестве шины стандартное решение - JGroups.

>Я так до конца не понял задачу

Задача - обеспечение совместной работы пользователей с разделяемыми ресурсами в распределенной среде.

в качестве шины стандартное решение - JGroups

А чем это будет удобнее использования JMS напрямую? (Как я понял, JGroups может работать поверх JMS)

Задача - обеспечение совместной работы пользователей с разделяемыми ресурсами в распределенной среде.

Тогда версионирование ресурсов самый безгеморройный вариант.

Задача - обеспечение совместной работы пользователей с разделяемыми ресурсами в распределенной среде.

Тут где-то ошибка или недопонимание. «Разделяемые ресурсы в распределенной среде» - это противоречит тому, что у тебя есть централизованная БД.

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

А чем это будет удобнее использования JMS напрямую? (Как я понял, JGroups может работать поверх JMS)

Тем, что проще. JMS - это надежная отправка через брокер, который хранит сообщения. JGroups - просто мультикаст. Разница между JGgoups и JMS примерно такая же, как между текстовым файлом и MySQL :)

JGroups вообще часто при построении кластеров используют. Он быстр и низкоуровенен. JMS - это интерпрайзный MOM.

>> Задача - обеспечение совместной работы пользователей с разделяемыми ресурсами в распределенной среде.

Тогда версионирование ресурсов самый безгеморройный вариант.

Версионирование ресурсов - это часть проблемы. Вот что, например, делать, когда параллельно на нескольких клиентских серверах осуществляется оформление документа на отгрузку товара со склада? Классическая проблема в учебниках, описывающих транзакционное поведение. При этом каждый из этих клиентов обращается за данными к одной из N реплик БД.

Вот что, например, делать, когда параллельно на нескольких клиентских серверах осуществляется оформление документа на отгрузку товара со склада?

С версионированием успеет выполнится первая транзакция, остальные отвалятся. Оператору сообщение: «упс, операция не выполнена, кто-то уже успел отгрузить товар». Если оформление заказа процесс долгий, то делается в 2 шага: вначале лочишь товар, потом уже формируешь заказ.

При этом каждый из этих клиентов обращается за данными к одной из N реплик БД.

Вот этого лучше сторонится как огня. Мастер-мастер репликация гемор еще тот.